fxruby users - Feb 2006 - create issue

dear lyle,
i want to propose a solution to an unecessary complication in fxruby:
calling create on widgets whose parents are not created yet!

in previous versions it caused a segfault in the latest versions it
results in application halt and this message: "trying to create window
before creating parent window."

i think it complicates code too much. now i often code something like that:

 wdg.create if App.instance.created?

therefore i had to wrap Fox::FXApp into a singleton class App which
remembers if it has been created yet. that''s a convenient workaround
for me but it is unnecessary.

but how about fxruby putting out a warning  "warning: trying to create
window before creating parent window." (a linenumber would be
confortable) and simply ignore that call if the application is not yet
created?
it would allow to reuse code without needing to worry about the
create-order-issue.

kind regards,
-- henon

On Feb 2, 2006, at 5:45 AM, Meinrad Recheis wrote:
> but how about fxruby putting out a warning  "warning: trying to create
> window before creating parent window." (a linenumber would be
> confortable) and simply ignore that call if the application is not yet
> created?
> it would allow to reuse code without needing to worry about the
> create-order-issue.
Henon,

I''ve added a feature request  
(http://rubyforge.org/tracker/index.php? 
func=detail&aid=3425&group_id=300&atid=1226) on this one;
I''m going to
have to think about it. It definitely won''t happen in FXRuby 1.4, but  
it is something we can consider doing for FXRuby 1.6 (which is just  
waiting on a final release of FOX 1.6).

All of the confusion surrounding when you need to call create(), and  
when you shouldn''t, etc. is probably the biggest problem that new FOX  
and FXRuby users deal with. I understand why Jeroen did things this  
way, but it doesn''t change the fact that I''ve answered more
questions
about create() than I can count! So I''m definitely interested in doing
something(s) in the FXRuby binding to address the problem.

Thanks,

Lyle

On Thursday 02 February 2006 05:45, Meinrad Recheis
wrote:
> dear lyle,
> i want to propose a solution to an unecessary complication in fxruby:
> calling create on widgets whose parents are not created yet!
> 
> in previous versions it caused a segfault in the latest versions it
> results in application halt and this message: "trying to create window
> before creating parent window."
> 
> i think it complicates code too much. now i often code something like that:
> 
>  wdg.create if App.instance.created?
> 
> therefore i had to wrap Fox::FXApp into a singleton class App which
> remembers if it has been created yet. that''s a convenient
workaround
> for me but it is unnecessary.
> 
> but how about fxruby putting out a warning  "warning: trying to create
> window before creating parent window." (a linenumber would be
> confortable) and simply ignore that call if the application is not yet
> created?
> it would allow to reuse code without needing to worry about the
> create-order-issue.
> 
> kind regards,
Just to explain a bit more about the create() issue:- in C++, objects are
not "complete" until the constructor has finished running.  Thus, an
object
can not be fully realized inside its constructor since what we think of
as a complete constructor may actually be only a part of the object, since
the developer could have subclassed the class.

Take e.g. FXButton.  There''s no way for me to tell if you have
subclassed
it or not, and thus I can not consider the FXButton to be fully constructed
at the end of FXButton''s constructor.  Indeed, all the vtable entries
at
that time still refer to FXButton''s vtable entries, and not the
developer''s
subclass thereof.

This explains the dichotomy between construction and creation.  We can do 
the latter only if the former is known to be completed.

There are also other reasons why it is needed; for example, we can construct
a widget tree [e.g. programmatically or by serialization] and not realize it 
until its complete.

Hope this helps,

		- Jeroen




-- 
+----------------------------------------------------------------------------+
| Copyright (C) 19:40 02/ 2/2006 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+