Argh, sorry about that. I read "File" and based on the amount of work I've recently done on the FileChooser I automatically assumed your question was referring to that. Apologies! In terms of the a method to fetch the appropriate filename, you can either use the method(s) that have been suggested already, or the code in src/FileChooser2.cxx regarding the value() method might help.
I promise I'll get around to rebuilding the docs this weekend! Regards, Ben. > From: [email protected] > Date: Fri, 27 May 2011 12:45:07 -0700 > To: [email protected] > Subject: Re: [fltk.general] Fetching file name/path from selected > iteminfltk2.x FileBrowser's ! > > > > > On 27.05.2011, at 21:08, anon wrote: > > >=20 > > > I will later. I have an actual gui class providing my app a specific = > > API so that the class can be reimplemented to use any toolkit. > > >=20 > > > I have done basic tests with FileChooser and unless it provides API to = > > strip it from unnecessary widgets (everything beside the actual file/dir = > > structure/tree) and also embed it inside a Window than it won't fir my = > > needs. > > >=20 > > > I've now sat down to look in the APIs to see if it does provide said = > > APIs, but it would be nice to hear what's your recommendation on this: = > > does it provide functionality for my aforementioned needs (two-paned = > > audio player) or should I keep examining FileBrowser + other parts of = > > FLTK ? > > > > I have not used FLTK 2 in a long while, so I may be wrong. But my memory = > > tells me this: FileBrowser is pretty mighty. You have so many options = > > that the easy access is somewhat blocked. You can use two FIleBorwser = > > widgets an limit the left one to show only directories while the right = > > one can probably be limited to files, using the type() and.or using = > > filename filters. > > > > Other than that, the browsers are hierarchies of widgets and are = > > accesses that way. When one item is clicked, IIRC you get a callback and = > > can use something like "last_clicked()" or similar to find the trigger = > > widget. That widget has a label that corresponds to that part of the = > > path. Add the Browser's director in front, and you have your file path. = > > The same should be true for the sound file browser. Whenever the user = > > clicks a path on the left, recalculate the file path and tell the right = > > browser to refresh. > > > > Thanks for the (fast) reply Matthias ! > Well I didn't find FileBrowser complex or anything, not at all. I was just > confused about the chosen file string, and I simply ignored the fact that > it's items are in fact widgets (the Browser::add() method should have ringed > a bell..). > Anyway it looks like it's this method: Widget * Browser::goto_focus();. > > Thanks for ringing the bell in my head :) > _______________________________________________ > fltk mailing list > [email protected] > http://lists.easysw.com/mailman/listinfo/fltk _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
