[Gambas-devel] Design property

[Robert Rowe]

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.
>
>