Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
@manolo: Great -- agree with all, except perhaps loosing const here: - const Fl_Window *win = (const Fl_Window*)this; + Fl_Widget *win = (Fl_Widget*)this; I think we can maintain const protection on the variable this way: const Fl_Widget *win = this; : return ((Fl_Widget*)win)-as_window(); Does that not throw a warning (or even an error) about casting away the const-ness of win, though? Without actually trying it, I imagined that it might... Maybe that's what Manolo was hoping to avoid? ..this ensures const protection for all uses of win within the code, and we only turn it off when we need to (eg. the non-const as_window() call) That certainly sounds like a worthy intent, if it does not trigger any compile-time issues. I suppose we could do a more C++ish cast instead, so the compiler would know we really meant it! (i.e. const_cast) Also, I should probably change all instances of 'win' - 'w' in the code, since it's really working with widgets now. Yes, I guess that would be right. Thanks for the peer review -- will hold on comments regarding const above, as am curious if there's a reason not to. I think we should go for it... Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
I have put the functions in Fl_Menu_Item namespace only because maming them that way seems to make sense. As far as I know, static functions (and static class variables) do not break ABI: they are not really class members, just additional ordinary functions and global variables with fancy naming sugar (functions with class namespace scope). For that matter even addition of a non-virtual class function should not break ABI either - any compiler guru can confirm this or am I wrong? I'm in favour of this change, if we are happy it's not ABI breaking. I'm not even sure, but Roman's discussion sounds right! Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) +1 for renaming to w instead of win (or maybe widget to avoid name clashes with w(), but that's not important here, IMO) +0 for maintaining constness (yes, I mean + zero). constness doesn't gain much here, and since compilers become pickier more and more, there is the danger of getting a warning when it's cast away for as_window(), as Ian wrote elsewhere. If not now, then maybe later. We're only calling const methods anyway, as x(), y(), window(), and this code is not subject to be changed in the future. Using const here would IMHO only protect ourselves from adding code that would modify the widget in question, and as said before, we won't add more code. Just my 2 (â¬)ct. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature Roman, this looks like a good idea, I recommend adding it, however with two caveats. I'll post them in followup messages. WRT ABI issues: adding flags and static methods doesn't break the ABI, so we should be safe here. Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature #2: I believe that the following part of this proposal should not be added as given: change code in function Fl_Menu_::picked() from line approx 271: ... else if(!(value_-flags Fl_Menu_Item::no_close_flags() (FL_SUBMENU | FL_SUBMENU_POINTER))) // do not execute parent's widget (common) callback if there is no direct menuitem callback assigned // and menu is not closed and isem is just a submenu (no valid item picked) do_callback(); } It think that not calling a callback for submenus is unrelated to the option not to close the menu when the item is clicked on. What if someone wants a callback when a submenu is clicked on, but doesn't want the menu to be closed? Setting the FL_MENU_NOCLOSE flag would prevent the callback from being called in this situation, if I understand correctly what is going on here. I don't really know why one would want a callback to be called when a submenu gets selected, but I can imagine that you could change the submenu before it is popped up (or popup()ed? ;-)). Also, I believe the code could be changed to be more clear, but maybe you did it as proposed because you had compatibility in mind. Wouldn't something like this be better? if ( !((value_-flags Fl_Menu_Item::no_close_flags()) (FL_SUBMENU | FL_SUBMENU_POINTER)) ) Well, I really don't grok it entirely now, but I hope you got my idea. This should be discussed further, and maybe a test programm would be fine. Roman, could you post one and describe a procedure to test what you want to achieve, so that we can see the effect when implementing it? Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) @Greg: Yes to all proposed changes. There's no reason, but laziness, to loose const protection. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Hi Albrecht,
1) To have global function (although as static in Fl_Menu_Item)
no_close_flags(int f) is to allow user simply to change begaviour globally
for isntance for all submenus by calling
Fl_Menu_Item::no_close_flags(FL_SUBMENU|FL_SUBMENU_POINTER);
Then it woult not be required to set any menuitem flag explicitly, so all
code (for instance fluid generated) would work with new behaviour as
expected
2) I an not against adding an extra FL_MENU_NOCLOSE enumeration flag, just
showing that this is unnecessary as it can be done by the user. Having
function no_close_flags() allows to control behaviour BOTH globaly and in
per-item fasion. But adding FL_MENU_NOCLOSE to api and setting by default
static int no_close_flags_ = FL_MENU_NOCLOSE;
or even to
static int no_close_flags_ = FL_MENU_NOCLOSE | FL_SUBMENU |
FL_SUBMENU_POINTER;
// breaks backward compatibility
is fine with me, although the second one breaks backward compatibility
3)
Your code
if ( !((value_-flags Fl_Menu_Item::no_close_flags()) (FL_SUBMENU |
FL_SUBMENU_POINTER)) )
does not make sense to me - second part (FL_SUBMENU |
FL_SUBMENU_POINTER) is a constant expression and is always true.
The code change as proposed is to assure strict backward compatibility:
submenus until now never called widget common callback (even when menu
is closed) with submenu-item picked. This is to avoid calling this
callback with wrong item picked - which can not be selected for instance
Fl_Choice with submenu (you can not set this Fl_Choice to the state with
submenu-item picked). However new code would indicate submenu-item as
picked during callback and could even crash a program if the program
relies that only ordinary items can be selected. The user still can assign
a callbback directly to submenu-item if he wishes so (probably a rare
case).
And yes, this is a real-life case: without the change one of my
applications with Fl_Choice with submenus crashed.
3) I would propose to have functions no_close_flags() NOT inlined to avoid
initialization fiasco (if somebody would call this before main() or some
crazy pal would call gui before main()), I would implement them in
Fl_Menu.cxx as
static int menu_no_close_flags_ = FL_MENU_NOCLOSE;
void Fl_Meu_Item::no_close_flags(int m){return menu_no_close_flags_ = m;}
int Fl_Meu_Item::no_close_flags(){return menu_no_close_flags_;}
Roman
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Ops, the second line from the bottom should be of course without return:
void Fl_Meu_Item::no_close_flags(int m){menu_no_close_flags_ = m;}
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) Albrecht We're only calling const methods anyway, as x(), y(), window(), Albrecht and this code is not subject to be changed in the future. Yes, though for some reason as_window() is not const, (it probably should be), which is why that cheat is necessary at the end there. Maybe using const_castFl_Widget*(w)-as_window() is better, which is what I decided to go with in top_window_offset().. will check. Note in manolo's implementation, const is cast away at the top at the declaration of the variable, but I just switched it to const and cast const away only at the place where it was needed, at the as_window() call. So this does two things: 1) Keeps the variable const so one can't later add code like w-label(yoo hoo); without getting an error.. hey, it could be more subtle ;) 2) Highlights exactly where the cheat is needed (at as_window()) so if as_window() ever changes in the future to be const, it's easier to find and remove the const cast-away. Is there a reason as_window() and friends (other virtual implementations) are not const methods? Fl_Window::window() is. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Hi Roman,
1) I didn't write that I didn't want that global flag, and I understood
what you wanted to achieve with it. That's all okay so far.
2) It was not the point that adding a new flag is unnecessary as it can
be done by the user. My point is: we should *avoid* to make the user set
any flags in the menu items except those that are defined in the library.
One argument is to be free to define other bits for new use cases within
the library w/o risking damage if a user defined exactly this bit for his
purposes (as it would be possible with your primary proposal). Therefore I
am for adding this extra bit to the enumeration within the library. Only
that was the reason to do it like Greg proposed, everything else just like
your proposal would be okay with me.
3) Yes, you're right, my code was bad - I was in a hurry. But I still
believe that the callback issue is another issue unrelated to the no_close
flag, so this shouldn't be mixed. However, I don't have the time to think
further about it now, so I'll post later regarding this.
4) to your new code proposals: okay with one exception: if we use the
FL_MENU_NOCLOSE flag, then it would be handy to change this one:
void Fl_Meu_Item::no_close_flags(int m){menu_no_close_flags_ =
m|FL_MENU_NOCLOSE;}
so that FL_MENU_NOCLOSE will always be set in the flags for testing.
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widgetthat returns its top-level window
On 12.04.2013 18:57, Greg Ercolano wrote: Albrecht We're only calling const methods anyway, as x(), y(), window(), Albrecht and this code is not subject to be changed in the future. Yes, though for some reason as_window() is not const, (it probably should be), which is why that cheat is necessary at the end there. Maybe using const_castFl_Widget*(w)-as_window() is better, which is what I decided to go with in top_window_offset().. will check. Using const_cast is only another way to write it, but means the same essentially, doesn't it? However, if some compilers wouldn't flag a warning for const_cast but would for the old-style cast, then we could maybe use it, but according to the CMP this shouldn't be used for fltk 1.1 code, however it should be used for 2.0 code. 1.3 code is not (yet) specified, so we'd have to make a decision about this first. Concerning as_window(): ISTR that the first proposal was const, but for some reason someone removed the const, but I'm not sure about it. Note in manolo's implementation, const is cast away at the top at the declaration of the variable, but I just switched it to const and cast const away only at the place where it was needed, at the as_window() call. So this does two things: 1) Keeps the variable const so one can't later add code like w-label(yoo hoo); without getting an error.. hey, it could be more subtle ;) Yep, that's what I wrote with other words, isn't it? You cited it above. I don't think that such a tiny method will ever be changed. However, I'm not against your proposal, please go ahead... 2) Highlights exactly where the cheat is needed (at as_window()) so if as_window() ever changes in the future to be const, it's easier to find and remove the const cast-away. Fair point. Is there a reason as_window() and friends (other virtual implementations) are not const methods? Fl_Window::window() is. You mean: Fl_Window* Fl_Widget::window() const is, right? Other than what ISTR (see above), I don't know. Probably Fl_Window* Fl_Widget::window() could be const as well, but can we change it w/o breaking the ABI? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl_Widget::as_window() and friends const ? [was: STR #2948: Add a method to Fl_Widget that returns its top-level window]
On 12.04.2013 19:44, Albrecht Schlosser wrote:
On 12.04.2013 18:57, Greg Ercolano wrote:
Is there a reason as_window() and friends (other virtual
implementations) are not const methods? Fl_Window::window() is.
You mean: Fl_Window* Fl_Widget::window() const is, right?
Other than what ISTR (see above), I don't know. Probably
Fl_Window* Fl_Widget::window() could be const as well, but
can we change it w/o breaking the ABI?
Hmm, I'm not a const and ABI specialist, I mean I don't know
all the implications that would arise if we changed this method.
That said, what about one additional method for each of these
that is const and returns a const pointer, like this patch:
Index: Fl_Widget.H
===
--- Fl_Widget.H (revision 9869)
+++ Fl_Widget.H (working copy)
@@ -964,6 +964,7 @@
\see Fl_Widget::as_group(), Fl_Widget::as_gl_window()
*/
virtual Fl_Window* as_window() {return 0;}
+ virtual const Fl_Window* as_window() const {return 0;}
/** Returns an Fl_Gl_Window pointer if this widget is an Fl_Gl_Window.
Index: Fl_Window.H
===
--- Fl_Window.H (revision 9869)
+++ Fl_Window.H (working copy)
@@ -459,6 +459,7 @@
// Note: Doxygen docs in Fl_Widget.H to avoid redundancy.
virtual Fl_Window* as_window() { return this; }
+ virtual const Fl_Window* as_window() const { return
const_castFl_Window*(this); }
/**
Changes the cursor for this window. This always calls the system, if
--- end of patch ---
This compiles well, but doesn't address all the siblings like as_group()
etc.
Note that I used const_cast that needs to be discussed as well.
Opinions anybody? Would this solve the problem? Would it break the ABI?
Other variants needed?
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method toFl_Widget that returns its top-level window
On 04/12/13 01:20, MacArthur, Ian (Selex ES, UK) wrote: @manolo: Great -- agree with all, except perhaps loosing const here: - const Fl_Window *win = (const Fl_Window*)this; + Fl_Widget *win = (Fl_Widget*)this; I think we can maintain const protection on the variable this way: const Fl_Widget *win = this; : return ((Fl_Widget*)win)-as_window(); Does that not throw a warning (or even an error) about casting away the const-ness of win, though? No complaints here; checked the mountain lion compiler, VS 2010, and the most recent linux compiler I have, 4.4.6 I don't see a way around casting away const, because we want to use as_window() which, for some reason (?) is not const itself. (Seems it should be a const method, just like window() is) That certainly sounds like a worthy intent, if it does not trigger any compile-time issues. I suppose we could do a more C++ish cast instead, so the compiler would know we really meant it! (i.e. const_cast) Yes, was thinking that myself, as I used that (a few lines up) at theend of the new top_window_offset() for the exact same reason (calling as_window()); will do that here as well, because that flies on all the compilers I have as well. I think we should go for it... Done; r9875 + r9876. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widgetthatreturns its top-level window
On 04/12/13 10:44, Albrecht Schlosser wrote: Yes, though for some reason as_window() is not const, (it probably should be), which is why that cheat is necessary at the end there. Maybe using const_castFl_Widget*(w)-as_window() is better, which is what I decided to go with in top_window_offset().. will check. Using const_cast is only another way to write it, but means the same essentially, doesn't it? Yes -- just more c++-esque. Should change it I think for two reasons; I already use it for the exact same reason in the new top_window_offset() method (just a few lines up from top_window()), and (2) it's probably clearer readability-wise that the goal is to explicitly cast away const (and not do something else, like a type conversion) However, if some compilers wouldn't flag a warning for const_cast but would for the old-style cast, then we could maybe use it, but according to the CMP this shouldn't be used for fltk 1.1 code, however it should be used for 2.0 code. 1.3 code is not (yet) specified, so we'd have to make a decision about this first. Open to alternative suggestions, but all the code provided here basically casts away const in one way or another, as we're defining a const method that starts with a pointer to 'this' (and therefore has to be const), but also need to call a non-const method as_window() through that pointer. Concerning as_window(): ISTR that the first proposal was const, but for some reason someone removed the const, but I'm not sure about it. Interesting; I'll try to track that conversation down, I'm kinda curious what the reason could possibly be. Seems the code implementation is pretty simple; it either returns '0' or 'this', and the virtual aspect handles the 'logic'. The method itself clearly makes no changes to the class, so it really could be const. 2) Highlights exactly where the cheat is needed (at as_window()) so if as_window() ever changes in the future to be const, it's easier to find and remove the const cast-away. Fair point. Is there a reason as_window() and friends (other virtual implementations) are not const methods? Fl_Window::window() is. You mean: Fl_Window* Fl_Widget::window() const is, right? Yes, emphasis on the method itself being const, not concerned with the return value. window() is a const method, but as_window() is not; seems odd. Other than what ISTR (see above), I don't know. Probably Fl_Window* Fl_Widget::window() could be const as well, but can we change it w/o breaking the ABI? I'm thinking you must have meant: Fl_Window* Fl_Widget::as_window() could be const as well ..emphasis on as_window() as opposed to window(), which already is const. Yes, too late to change I think, unless protected with our friend the ABI macro. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Widget::as_window() and friends const ? [was: STR #2948: Adda method to Fl_Widget that returns its top-level window]
On 04/12/13 11:05, Albrecht Schlosser wrote: Hmm, I'm not a const and ABI specialist, I mean I don't know all the implications that would arise if we changed this method. Ya, I'll have to double check that one, but I think changing the prototypes (args, return values) of existing methods affects ABI, but perhaps not const.. You'd think it wouldn't matter, as const is not really a data size thing, it's just a permissions thing. But not sure. If for no other reason, macro'ing it out would allow it to be investigated easily, and concurrently flagged to be part of the next release. That said, what about one additional method for each of these that is const and returns a const pointer, like this patch: I'm not expert on this either. I'm thinking as_window() (and friends) should be more like the window() prototype (const method, returns non-const pointer) if for no other reason, just to be consistent. window() has been around for a looong time, and I don't think anyone's ever requested const variations, so not sure variations would be needed..? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widgetthat returns its top-level window
On 12 Apr 2013, at 18:44, Albrecht Schlosser wrote: Using const_cast is only another way to write it, but means the same essentially, doesn't it? However, if some compilers wouldn't flag a warning for const_cast but would for the old-style cast, then we could maybe use it, but according to the CMP this shouldn't be used for fltk 1.1 code, however it should be used for 2.0 code. 1.3 code is not (yet) specified, so we'd have to make a decision about this first. I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method toFl_Widgetthat returns its top-level window
On 04/12/13 13:19, Ian MacArthur wrote: I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? The static_cast mod flew in all my tests on redhat9 and irix6.5, and those are as old as the friggin hills. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) Updated fixes in r9875 and r9876. About to close, unless there's more to add. Regarding const mods to at_window() and friends, let's continue that on fltk.dev and make a separate STR for that. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) Oh, I should add.. all mods to date (r9876, including static_cast) build OK on: redhat9, irix6.5, centos 5.6, Mountain Lion default compiler (picky), Sci Linux 6 (very picky, latest linux I have) gcc 4.4.6, and VS 2010. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method toFl_Widgetthat returns its top-level window
On 13 Apr 2013, at 00:07, Greg Ercolano wrote: On 04/12/13 13:19, Ian MacArthur wrote: I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? The static_cast mod flew in all my tests on redhat9 and irix6.5, and those are as old as the friggin hills. You say static_cast here? Would we not be wanting const_cast in this case...? Or am I missing something obvious again? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) Sorry, as Ian points out on fltk.dev, meant to say const_cast in the above, not static_cast. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a methodtoFl_Widgetthat returns its top-level window
On 04/12/13 16:17, Ian MacArthur wrote: The static_cast mod flew in all my tests on redhat9 and irix6.5, and those are as old as the friggin hills. You say static_cast here? Bleh, mental typo. I meant this: $ grep const_cast Fl_Window.cxx return const_castFl_Widget*(w)-as_window();// return if window, or NULL if not return const_castFl_Widget*(w)-as_window(); ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
