Re: [fltk.bugs] [HIGH] STR #2761: Force break when wrapping long words

2011-12-12 Thread David
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2761 Version: 1.3-current I thought fl_choice had the problem too, I could have sworn it cut it off. I think I know why, the string had an @ in it and it was cutoff

Re: [fltk.bugs] [HIGH] STR #2761: Force break when wrapping long words

2011-12-12 Thread David
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2761 Version: 1.3-current Attached file test_v2.cxx... Link: http://www.fltk.org/str.php?L2761 Version: 1.3-current#include FL/Fl.H #include FL/Fl_Window.H #include

Re: [fltk.bugs] [HIGH] STR #2761: Force break when wrapping long words

2011-12-12 Thread Greg Ercolano
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2761 Version: 1.3-current Sounds like maybe we need an FL_ALIGN_WRAP_HARD to hard break lines. This could then be backwards compatible. Link:

Re: [fltk.bugs] [HIGH] STR #2761: Force break when wrapping long words

2011-12-12 Thread David
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2761 Version: 1.3-current needs to work any time you want to call on fl_measure ( in addition to fl_draw or fl_expand_text) so would need additional code to handle a new

Re: [fltk.general] Good tutorial for complex drawing functions

2011-12-12 Thread MacArthur, Ian (SELEX GALILEO, UK)
What I want to do is something very simple, in the past I wrote a program to display millions of rectangles, each is an widget, being selectable and completely filled with an fl_rect, with a tooltip with its name and selectable rectangle colors (a viewer for semiconductor placements).

[fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread David FLEURY
Hi, I am testing fltk layout using Fl_Pack, but I have an issue I did not succeed to solve. If I resize manually my window, everything is fine, but if I use the window-size method (launching the exe with an arg), my buttons resize too... which is different from the manual resizing. Can

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread MacArthur, Ian (SELEX GALILEO, UK)
I suspect (i.e. I haven't looked all that closely) that the problem is the order of events... int main( int argc, char** argv ) { Fl_Window* second = SecondTry( 350,50); if ( argc 1 ) second-size(800,600); second-show(); If argc is 1 then size() is called before the second window is

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread David FLEURY
I suspect (i.e. I haven't looked all that closely) that the problem is the order of events... int main( int argc, char** argv ) { Fl_Window* second =3D SecondTry( 350,50); if ( argc 1 ) second-size(800,600); second-show(); If argc is 1 then size() is called before the second

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread MacArthur, Ian (SELEX GALILEO, UK)
I suspect (i.e. I haven't looked all that closely) that the problem is the order of events... int main( int argc, char** argv ) { Fl_Window* second =3D SecondTry( 350,50); if ( argc 1 ) second-size(800,600); second-show(); If argc is 1 then size() is called before

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread David FLEURY
Huh? OK, I just tested, and it does work - but they window has to be mapped first, so simply calling show() on it is not enough, the window actually has to have been drawn... Ok. My fault, I misunderstood mapped. I have done size() after show() but without a pause. I though show was

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread Albrecht Schlosser
On 12.12.2011 17:36, MacArthur, Ian (SELEX GALILEO, UK) wrote: OK, I just tested, and it does work - but they window has to be mapped first, so simply calling show() on it is not enough, the window actually has to have been drawn... Yep, that's one of the problems with Fl_Pack I discussed

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread David FLEURY
[...] // resize the window programaticaly, after it is mapped else if (argc == 1) { Fl::check(); Fl::check(); second-size(900,700); } I believe that I tested it, but I deleted it before finishing this posting. It works fine. Anyway, I agree with Ian that using

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread Albrecht Schlosser
On 12.12.2011 20:15, David FLEURY wrote: [...] // resize the window programaticaly, after it is mapped else if (argc == 1) { Fl::check(); Fl::check(); second-size(900,700); } I believe that I tested it, but I deleted it before finishing this posting. It

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread David FLEURY
[...] It's easy to do spacing with a minimal subroutine to save current positions, add some pixels, or do anything you like. I though that was the goal of Fl_Pack here. But ok. Don't write coordinates literally - that *will* become a nightmare if you want to add widgets later. Did you

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread David FLEURY
[...] It's easy to do spacing with a minimal subroutine to save current positions, add some pixels, or do anything you like. Here my 10 minutes attemp before sleep... You were right quite easy. I will try to make one that can be use nested. Thanks. #include FL/Fl.H #include

Re: [fltk.general] Fl_window::size vs Manual resizing

2011-12-12 Thread Greg Ercolano
Thought I'd join in; does this use of Fl_Pack help? For demo purposes, I changed the first two buttons to change the size() of the window. This maybe can avoid having a custom packer, lets you use Fl_Pack to organize the buttons, and lets you resize the