🚀 go-pugleaf

Sven Goetgeluck wrote:

> hi ,
> when using my dialogs in jb 9 i'll get a red component in design mode
> what can i do about it?
> all my dialogs are extended from myescdialog so i dont have to put all the
> code agian for reacting on esc button press
> 
>   a.. Failed to create live instance for variable 'this'.
> components.dialogs.MyESCDialog
>   b.. Failed to create live visual subcomponent this as
> components.dialogs.MyESCDialog(cls); creating a red component in its place
> 
> is there a wourk around??

The JBuilder Help discussion on "red beans"
indicates why this happens: the Designer
cannot instantiate a class which does not
have a no-parameter constructor.  Dialog
and its descendants violate that requirement;
hence the red bean.  The Help also says that
one should consult the Release Notes in the
JBuilder installation directory.


To get around this with dialogs, one typically designs
the components (sub-panels) of a dialog as separate
classes (extensions of JPanel) and uses those
in a new JDialog.  That is, one doesn't subclass
JDialog.  So, in your case, where you seem to
have a button which you want to use in a number
of dialogs, you would create a class which extends
from JPanel, call it "MySpecialButtonPanel", place
your button on it, add accessor/mutator methods
to get at the button (e.g., to add/remove listeners),
and add that panel to any new dialog you create.



-- 


Paul Furbacher (TeamB)

   Save time, search the archives:
        http://www.borland.com/newsgroups/ngsearch.html

   Is it in Joi Ellis's Faq-O-Matic?
        http://www.visi.com/~gyles19/fom-serve/cache/1.html

   Finally, please send responses to the newsgroup only.
   That means, do not send email directly to me.
   Thank you.

Paul Furbacher <pfurbacher@mac.com> writes:

> The JBuilder Help discussion on "red beans"
> indicates why this happens: the Designer
> cannot instantiate a class which does not
> have a no-parameter constructor.

For completeness' sake I'd also like to mention the two other cases
where it can happen:

1) When the no-arg constructor throws an exception. To overcome this
   you often need to surround code that's only relevant at run-time
   with

	if (!java.beans.Beans.isDesignTime()) {
		// ...
	}

2) When the component extends an abstract class. The solution is to
   declare a "proxy" concrete class for the designer.

"Tor Iver Wilhelmsen (TeamB)" <tor.wilhelmsen@ergo.no> schreef in bericht
news:usmhx289b.fsf@ergo.no...
> Paul Furbacher <pfurbacher@mac.com> writes:
>
> > The JBuilder Help discussion on "red beans"
> > indicates why this happens: the Designer
> > cannot instantiate a class which does not
> > have a no-parameter constructor.
>
> For completeness' sake I'd also like to mention the two other cases
> where it can happen:
>
> 1) When the no-arg constructor throws an exception. To overcome this
>    you often need to surround code that's only relevant at run-time
>    with
>
> if (!java.beans.Beans.isDesignTime()) {
> // ...
> }
>
> 2) When the component extends an abstract class. The solution is to
>    declare a "proxy" concrete class for the designer.

so i cannot do it the way i do it extends from jdialog ,
in jb 3 is worked perfect

what is ment by a "declare proxy concrete class"

sven

Sven Goetgeluck wrote:

>>2) When the component extends an abstract class. The solution is to
>>   declare a "proxy" concrete class for the designer.
> 
> 
> so i cannot do it the way i do it extends from jdialog ,
> in jb 3 is worked perfect

JBuilder 3 was based on a hybrid of Java and Delphi.
I don't know whether the Designer was a Delphi
component, but to make comparisons between the
two products isn't very meaningful.

> what is ment by a "declare proxy concrete class"

The release_notes.html file, which I mentioned earlier,
explain this.  Please do read this file.  It's found
in the root directory of your JBuilder installation:
e.g.,

   d:/JBuilderX/release_notes.html

Click on the link to "Designer" in the Table
of Contents.

I still think that you should consider
aggregation instead of inheritance here.
I consider a dialog as a functional shell into
which one aggregates viewable components.
Maybe that's too limiting, but that's how
I look at it.  And so far, that view has
served me well: it tends to make the viewable
components I write re-usable in more than just
a single dialog class hierarchy, and avoids
the red bean problem entirely.


-- 


Paul Furbacher (TeamB)

   Save time, search the archives:
        http://www.borland.com/newsgroups/ngsearch.html

   Is it in Joi Ellis's Faq-O-Matic?
        http://www.visi.com/~gyles19/fom-serve/cache/1.html

   Finally, please send responses to the newsgroup only.
   That means, do not send email directly to me.
   Thank you.

"Paul Furbacher" <pfurbacher@mac.com> wrote in message news:401995d7
...
> To get around this with dialogs, one typically designs
> the components (sub-panels) of a dialog as separate
> classes (extensions of JPanel) and uses those
> in a new JDialog.  That is, one doesn't subclass
> JDialog.  ...

Or just be sure that you provide a no-argument public constructor to your
subclass of JDialog to appease the designer(in addition to making the class
public). Your code does not have to use it, but the Designer will. If you
want, you can put code in the no-argument constuctor so that it throws an
exception if  it is ever called outside of the designer.

if (!java.beans.Beans.isDesignTime())
           throw new RuntimeException("Do no use this constuctor");

 to make sure that it is never used in real life.