[Gambas-devel] Design property

[Fabien Bodard]

In fact the problem of your thinking way, is that you want your component
manage the ide editing.

you must to study better the way that the gb.form component is working.

The gambas form editing model is based on the container model. So imagin a
toobar that arrange it's content in the zOrder order. Imagin a dockable
toolbar... don't try to link hardly the widgets contained in it.... use the
container child array to parse the widgets contained. Make the toolbar more
dynamic.  You are thinking in a VB old model... (nevertheless VB no have
widgetAdd function). Study the reparent function... you are trying to do
something too complex and not so easy to use...

This is my opinion...

Regards,

Fabien Bodard


2008/4/5, Robert Rowe <robert.c.rowe at ...176...>:
>
> The idea of a faux property had occurred to me. Since the IDE didn't
> currently support it I thought that I could at least provide something
> for my control. I had the impression from looking at other controls
> (texbox, etc) that some design time interaction was possible. I guess
> that these controls are written in C++ and have capabilities that the
> gambas made controls do not. Maybe we could work on this at some time in
> the future.
>
> I actually did look at your toolbar. It is a well made flexible control.
> It's basically a smart container that can do some switching around of
> its children at runtime by changing properties. The developer still has
> to draw each button manually, carefully sizing and positioning them. I
> was messed up by this when working on the IDE because I didn't see the
> empty panel that you used as a separator. I'm not trying to knock your
> toolbar I just thought that I could write something that was easier to
> use and more flexible.
>
> I must have misunderstood what you meant the Action class to do. I
> thought that you wanted to basically automate the KeyPress code that
> would be necessary to catch hotkeys and to (optionally) append the key
> combo to the tooltip property.  Your idea is apparently a bit grander
> than I had thought. I do have an action property for each tool and I am
> planning to hook up with the action class once it is available. This
> could actually simplify the setup of my toolbar even further.  I could
> move the setting of the action to the third  parameter so that if the
> developer is using the action class then they could omit the rest of the
> parameters. I would get this information from the action class. I'm
> assuming that I would have to notify the action class when a button is
> clicked so that it can raise it's event. Maybe I would get this for free
> by simply setting the action property of the underlying toolbutton that
> I create. Once you have decided how the action class is to work I'll add
> the code to integrate it.
>
> I don't see why any of this would require a rewrite of my code. It
> sounds like additional stuff that could optionally be used. Maybe the
> developer will choose to not use the action class. I'd like to have it
> be able to work either way. Similarly I'd like to support both GUI setup
> and code setup as different developers work differently. There shouldn't
> be a need to make it only support one way.
>
> When I consider the toolbar to be as complete as possible I'll look into
> adding the IDE feature.
>
> Is there a simpler way to distribute it than the instructions that I
> provided? I worked from the instructions for installation of the
> grideditor component which was the only third party component that I
> could find.
>
>
> Robert Rowe
>
> Benoit Minisini wrote:
>
> > On vendredi 4 avril 2008, Robert Rowe wrote:
> >
> >> What I'd like to do is to display a button on the control at design
> >> time. When the developer clicks the button it brings up a GUI that lets
> >> them create/edit the tools on the toolbar. I'd save these settings
> >> somewhere. Either in the form file or another file in the project's data
> >> directory. The control would look for this file at runtime and load the
> >> tools from it. I hope to provide codeless setup and use of the toolbar.
> >>
> >> I can't seem to get any code that I put into a
> >>
> >> If me.Design Then
> >>
> >> block to run. I've also tried me.parent.design within the primary
> >> control in my component. This doesn't run either.
> >>
> >> Any suggestions?
> >>
> >> Robert Rowe
> >>
> >>
> >
> > This is not possible at the moment. All controls put in the form editor
> are
> > their Design property set, and so become completely insensitive.
> >
> > Actually you are two cases:
> >
> > - If the control belongs to a component used by the IDE, then the IDE
> displays
> > it with the Design property set.
> >
> > - Otherwise, the IDE uses a DrawingArea instead, and draws the control
> icon
> > inside, with its name.
> >
> > But all is managed by the IDE code.
> >
> > If you want something like that, you must modify the IDE this way:
> >
> > - Some controls can be configured by a dialog box. Not only yours, but
> for
> > example we can imagine that ColumnView initial columns properties could
> be
> > defined by a dialog box, as in VB.
> >
> > - The configuration dialog box are defined inside the IDE source code, by
> > using the control class inside the form name: FConfigureColumnView,
> > FConfigureRobertToolBar, and so on... This is not so horrible, as these
> > dialog boxes are useful only inside the IDE.
> >
> > - A "Configure" button inside a "simulated" property should be added to
> the
> > property sheet for this control.
> >
> > - These dialog boxes should provide a routine that creates the data for
> the
> > *.form file, and do the contrary: extract from the *.form file the
> > configuration data. This is the most complex part of the story, as each
> line
> > of the *.form file is actually part of a Gambas line of code (setting a
> > property usually), and so some trick must be added to the read/write
> routines
> > of the FForm form.
> >
> > Let's come back to your UCToolbar now: why didn't you take the Toolbar
> code
> > and just modified it? You would have got a normal container.
> >
> > And as I told you before, modifying the Action class can make this
> control
> > useless. Not the code itself, as it could be moved to the Toolbar
> control.
> > But then it would take its data directly from the Action class (label,
> icons,
> > shortcuts...). The job is then to make a dialog box for defining all
> action
> > properties (a bit like the menu dialog editor).
> >
> > What do you think about that?
> >
> > If you want to continue working on that and rewriting your code, I will
> start
> > to work on the Action class so that you can do that easily.
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080426/0f5a881c/attachment.html>