If you create a container control, in the IDE, is the intent that you add methods to the container control as you would a class?
or does one define an interface and have the container control implement it implement it?
Yes, you add methods. You could define an interface. But why?
I let the containers communicate with the window by events. Then I make most of the methods in the container private so that there are only very few public methods. But for most communication I now use notifications.
[quote=480432:@Brian O’Brien]If you create a container control, in the IDE, is the intent that you add methods to the container control as you would a class?
or does one define an interface and have the container control implement it[/quote]
Generally speaking, I think when using Container Controls, the design goal is that any controls you place inside a Container should be marked as Private scope, so that nothing outside of the Container can or should be able to access those controls (deliberately or inadvertently).
So if the above is a preferred design goal for your project, then yes, you then want to add Public Methods, Events and/or Properties to the Container itself to interact with the inner contained Private controls.
An Interface is then useful if you plan in your code design to reuse your Container Control to create more than one variation of your Container. In which case, your interface would generally only implement the “generic” Methods that are useful for each of your control variations, e.g., Methods to “Set” and “Get” data in & out of the Container, or common Events used by each.
With the above in mind, I would build the Container Control first, then once you’re satisfied with the functionality, right-click on the Container Control in the IDE and choose “Extract Interface…” to save yourself some steps. This way you get a working Interface quickly, which you can then pair down to the limited common Methods you want to implement on the next Container.
I did this recently with some Containers that I use as views to display a common set of controls, when clicking on specific kinds of records in a Listbox.
Note: Strictly speaking an Interface is not required, but is useful for the idea of re-usability. The only down-side to Interfaces in Xojo (at this time) is that Interfaces appear to only support Methods and not Properties or Event Definitions. But I usually just add a Note to remind me what I need to add (and why).
I hope that helps to answer your question. Good luck!
for container controls are computed properties really useful.
but it is difficult to find a name that is not a key word^^
agree i missing that too …
No: use “_MR” (without quotes) as a suffix of whatever name you want. (for example)
Edit:
I use FI as suffix for FolderItem variables;
PB as prefix for PushButtons
TA_ or TF_ as Prefix for
TextArea and TextField
You understand the idea.
[quote=480458:@Emile Schwarz]No: use “_MR” (without quotes) as a suffix of whatever name you want. (for example)
Edit:
I use FI as suffix for FolderItem variables;
PB as prefix for PushButtons
TA_ or TF_ as Prefix for
TextArea and TextField
You understand the idea.[/quote]
I have not seen a need to add the type to a variable since I was a Windows system programmer coding in C and there was a need for Hungarian notation.
These days, my naming convention is simple:
- Class definitions begin with T and Interfaces with I, so the real name is still available for use as a variable
- Event definitions begin with On to make them easy to find among the framework events
- Private and protected properties begin with m, except for Id which is usually called mRecordId
- Labels end with Title
Thus for a UI component, mFirstNameTitle would be the label, mFirstName the input control and firstName can be used as a variable name.
properties with prefix / suffix makes the source code looks pretty ugly.
in case of computed properties for controls in container controls your idea is ok.
As for pretty versus readable, I’ll go for readability every time. The days of 2 character Commodore BASIC variable naming is long behind us.
I use a combo of both Emile and James’ methods. Served me well for far longer than I’ve been involved with RS/Xojo 
[quote=480456:@Markus Rauch]for container controls are computed properties really useful.
but it is difficult to find a name that is not a key word^^
agree i missing that too …[/quote]
A pair of methods can be made to be semantically and even syntactically indistinguishable from a property (computed or otherwise)
The code that USES this interface has no means of knowing if indeed it is a property or get/set method pair without introspection
And thats the point of an interface - to define the API but NOT the implementation of that api
If you need a “property” define it as
function myProperty() as type
end function
sub myProperty(assigns value as type)
end sub
and then ANY implementor can have this “property” and it can be computed, statiuc, fecthed on demand from the file system or ANYTHING you can dream of
[quote=480461:@James Dooley]I have not seen a need to add the type to a variable since I was a Windows system programmer coding in C and there was a need for Hungarian notation.
[/quote]
Systems or Application Hungarian ? 
One worked well - the other was a mess and got it totally wrong (see https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/)
it did not change the fact that every keyword or class name is in conflict with a propertie name and that happens really often.
@Norman Palardy
in a interface? i can not copy this two methods into.
[quote=480514:@Markus Rauch]
@Norman Palardy
in a interface? i can not copy this two methods into.[/quote]
interfaces do not provide the implementation
they specify an API that the implementor promises to implement - completely (and they happen to define a new data type you can use with ISA which is also handy as heck)
Suppose your interface has a means to ask for the “count” of something
Some implementors may simply keep a static array or dictionary and can return the count of those items
Some implementors may need to dynamically get the count - perhps the implementor needs a count of folderitems and since people can add and remove these without your class’ knowledge it probably should be dynamically retrieved from the file system.
If your interface said “Count” must be a property, defined simply as an integer, this would be a problem for that dynamic use case.
But, making “Count() as Integer” something each implementor has to add and implement in its own way, you get a known API (the interface) but the flexibility fo implement it differently as needed
And from outside that interface you cannot tell its done this way
Is myListBox.ListCount a property ? a computed property ? or a method called “ListCount” that returns an integer ?
dim i as integer = myListBox.ListCountin most cases you do not care nor is it relevant
You use it as if it is a “property” (something that can be read and set) and you move on
[quote=480507:@Norman Palardy]A pair of methods can be made to be semantically and even syntactically indistinguishable from a property (computed or otherwise)
The code that USES this interface has no means of knowing if indeed it is a property or get/set method pair without introspection
And thats the point of an interface - to define the API but NOT the implementation of that api
If you need a “property” define it as
function myProperty() as type
end function
sub myProperty(assigns value as type)
end sub
and then ANY implementor can have this “property” and it can be computed, statiuc, fecthed on demand from the file system or ANYTHING you can dream of[/quote]
You’re quite right Norman, as usual 
I was recently playing around with how a Method can act as a Property using Assigns.
I didn’t clue in at the time that this would a very good substitute for implementing/storing property-like definitions in an Interface.
Thank you!
yes, your example was without and only a definition.
i think a interface can not have the same method name twice.
[code] function myProperty() as type
end function
sub myProperty(assigns value as type)
end sub[/code]
its more
function GetPropertyName() as type
sub SetPropertyName(assigns value as type)
then it is a workaround and not listed as property if you have a class with this interface.
my thought was to define also a property as interface. if you have a class you just select a interface and bam all
properties are there. (instead of define them in a base class)
this ABSOLUTELY works because they have 2 completely different signatures
try it
and it works whether its in an interface OR just on some class that isnt using or implementing an interface
no - you DO NOT need to do this
do the overloaded methods and it works perfectly fine - but yes the method will NOT be listed as “properties” but they BEHAVE as if they were getting & setting a property
[quote=480547:@Norman Palardy]this ABSOLUTELY works because they have 2 completely different signatures
try it[/quote]
at least i tried to copy/paste your example into a interface but only one method appear for some reason.
oh I have no expectation you CAN copy paste from the forums into the IDE’
but you can certainly create methods like I described
I do this all the time
[quote=480564:@Norman Palardy]oh I have no expectation you CAN copy paste from the forums into the IDE’
but you can certainly create methods like I described
I do this all the time[/quote]
ok i will test this later. its valuable 
I love the interface idea… makes my coding a lot faster (i don’t have to define methods over and over again)…
but… no events?!
Visual Basic eventually added a With Events definition didn’t it?
I’m considering adding a RaiseEvent method to every interface that is
RaiseEvent(EventName as string, ParamArray params() as variant) as variant
at firs tglance event definitions seem like they could be a plausible addition since they dont specify how something is implemented
they too just specify WHAT is to be implemented
dunno if any one ever asked event defs be added to an interface