MacArthur, Ian (SELEX GALILEO, UK) wrote:
>
>> Today I'm converting one application to FLTK and found that
>> Fl_Help_View
>> doesn't call Fl_Help_View::link when user click's on a link,
>> although
>> the FLTK manual says that it does.
>
> And indeed, in my tests, it does. In what way does it not work for you?
>
> If you follow through the logic of ::follow_link(...) you will see that,
> after parsing the link that it was passed, it ultimately calls load() on
> that page, hence "following" the link.
>
> If it does not, I'd have to guess that, for some reason, it is not
> managing to parse out your links or something?
>
>
>> I added this code to it temporary to make it works:
>>
>> void Fl_Help_View::follow_link( Fl_Help_Link *linkp ) {
>> char target[32]; // Current target
>>
>> clear_selection();
>>
>> //new code begin
>> if( link_ ) {
>> if(!(*link_)(this, linkp->name)) return;
>> }
>> //new code end
>
> No, I don't think this is necessary, or correct...
>
>
What I expect based on other html widgets is an event that tells me that
a link was clicked and on this event/methos call I can:
1- Know what link/anchor was clicked.
2- I can choose to let the html widget perform it's default link click
handling or I can do something different and abort it's default.
On the application I'm converting right now I use link/anchors to allow
user choose some actions that doesn't imply load a new document, like
mark a record for special purposes, open a new window with a detailed
view of the selection/link/anchor, open a popup for options, ...
And only telling us that a user clicked on loading a new document isn't
enough.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
