[Gambas-user] Custom controls, Non-String arrays in the IDE

Benoit Minisini benoit.minisini at gambas-basic.org
Wed Aug 10 15:07:34 CEST 2022

Le 10/08/2022 à 14:49, bb a écrit :
> On Wed, 2022-08-10 at 13:13 +0100, Bruce Steers wrote:
>> On Wed, 10 Aug 2022 at 11:53, Bruce Steers <bsteers4 at gmail.com>
>> wrote:
>>> You know how you can put the following in a custom control..
>>> *Public Const _Properties As String = "*,StringArray"*
>>> *Property StringArray As String[] Use $aStringArray*
>>> Then in the IDE form designer you'll get the StringArray property
>>> and get
>>> an editor to insert strings to the list.
>>> If i use ANY other type like Integer[] or Float[] then it does not
>>> work
>>> the same. i just get a combobox with "none" to select, and if i do
>>> select
>>> none i then have to manually edit the .form file to remove the def
>>> as it
>>> raises an error.
>>> Could the form designer also handle other types?
>>> Integer[] and Float[] shouldn't be too hard to handle.
>>> The existing string[] editor could be used then the items converted
>>> to
>>> their respective type array.
>>> Would open up a few things for me.
>>> I'm trying to add gradients to a control and want to handle the
>>> Colors[]
>>> and StopPoints[] in the IDE
>>> Can some method be added to a Custom control class that the IDE can
>>> use to
>>> pop up our own editor window ?
>>> Something like this maybe?..
>>> *Public Const _Properties As String = "*,IntegerArray{IntList()}"*
>>> *Private Sub IntList() As Integer[]*
>>> *  FGetIntegers.ShowModal()*
>>> *  Return FGetIntegers.List*
>>> *End*
>>> then FIntegers pops open my own list editor
>>> Is something like this already possible ?
>>> Respects
>>> BruceS
>> I'm thinking my second idea of letting us create a custom property
>> editor
>> window that could return any type required would be a lot more useful
>> than
>> just making Integer[] Float[] also work in the form designer.
>> Possibly even less code as you'd just have to check for () in the
>> _Properties def "*, MyPropertyName{type_is_method()}" then set the
>> property
>> edit button in the IDE to run the method and pass it's return data
>> straight
>> to the property.
>> Hmm, When i put it that way it does sound like a fairly simple
>> addition.  I
>> might just have a browse through the IDE code and see if i can find
>> the way.
>> Respects
>> BruceS
>> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
> Have a look at the "special" property editors used in the Report
> designer. Although they are implemented inside the IDE, it could give
> you the points at which you'd need to apply some surgery to the IDE.
> I did something like this years ago that let me design the property
> editor inside the component rather than imposing changes on the IDE.
> I just had a look at where I knew that I had used it in one component
> and unfortunately I have disabled the said code and removed the
> necessary changes to the IDE - sad as it did work a treat.
> My use was far above what you are trying but I bit on the "custom
> property editor".
>  From memory the changes in the IDE were not that extravagant, the
> tricky bit is getting the IDE to load the component and look for the
> property editor in there.
> hth
> b

Mmm... No, thanks. I didn't want the IDE to load arbitrary components, 
and I still have the same opinion (for security reasons at least).

This is why all property types are directly handled by the IDE form editor.

As for the type of property you want to implement, are you sure that 
defining a gradient from the form editor is really worth it in your context?

A brush property type has been implemented for the Report forms, but 
it's because having a visual representation of what you are printing may 
be useful. It handles all brush types (and so gradients), even if 
printing gradients should be forbidden by the law of good taste.


Benoît Minisini.

More information about the User mailing list