I find the IDE quite difficult when there are a lot of controls and methods and properties etc in a Window, Containers, custom classes etc.
Is there any way of grouping methods into “folders” for example so that navigating a growing project isn’t quite so difficult? Does anyone think this would be useful? I would also love to be able to “turn off” the facility to see every item of a control array as I don’t particularly care about the indidual members of a control array.
To try to keep things simple, visually, I tend to create an array of buttons, say, or whatever I need with multiple instances. Then in the Action event I do a Select Case Me.Index and then I have a long list of routines - Case 0 Do This, Case 1 Do That etc. So I don’t really want a visual list of 20 array buttons or whatever cluttering up the interface. I know you might argue that this is tending to the procedural rather than the object-oriented but it’s the only way I can think of to avoid having umpteen different names for buttons, umpteen different names for TextFields etc - and still the IDE wants me to have to navigate its long lists of things.
Is it just me? Or does anybody else have this difficulty?
I wouldn’t create a Control Set/Array unless there’s a reason for it and this doesn’t seem a good reason. Without unique names how do you refer to controls? I mean I know how you’d do it but it’s so generic and fragile, change the indexing or remove a control and it all falls apart with no easy way to track down.
I would create umpteen names for each control, ones that describe or represent what they do. This makes it more readable to say “angle = Val(AngleField.Text)” rather than “angle = Val(FieldArray(7))”.
If there’s only a small number of controls, properties or methods I’ll just give them straight names. But if there’s going to be a whole whole lot then I use a name prefix to group things. You’ll still get a long list but it’s easier to find things by subject. for example
It’s not so much the controls that give me problems. I have, for example, a custom class with a growing number of methods, more than 20 at the moment. I have just tried to reorganise and noticing that 4 take text and output to other things, while four take input from other things and create text things, I would dearly love to have a folder in my methods list I could call texts. I could put methods in there called, for example, exFile, exTextArea and adListBox, adDatabase or whatever. All I can think of to do to reduce the clutter at the moment is to create a method called texts. In that method I Case Select a Text code (“exFile”, “exTextArea” etc) which works but of course all the methods have to have the same parameter inputs and return types and I have to get round this by having a lot of optional parameters. It’s just another kind of messy. I don’t know why it should be so difficult to create a folder of methods in a class.
As to a buttons array, you are probably right but with maybe 12 buttons I am happier to keep the code in one place and check the index of the button pressed. I’m not sure why I have to get a list of 12 identical buttons in the ide.
As to text fields, I could have up to 128 all behaving in similar ways so it seems much more sensible to code them as an array. Thanks for your input!
Name prefixing works for anything, Controls, Methods, Properties, Constants… Your example looks like it already has ‘ex’ and ‘ad’ prefixes. Group them further
Type ‘text’ and autocomplete will show just them, and they will all be next to each other in the navigator. If you forget the prefix the regularity makes them easier to scan for.
Note, I’m just suggesting a workaround for not having actual groups. I’ve brought this idea up before but didn’t get much/any interest and found prefixing is the best I could get.
To get actual groups you should file or add to a feature request. There’s only this one I could find from 4 1/2 years ago <https://xojo.com/issue/19656>
One problem I’d still have with actual groups is it only helps in the navigator. Autocomplete is were I’m usually searching for items so the groups would need to show up there and collapse away when selected. Or maybe the group would be part of the path, ie f=obj.text.exFile.
I have a class with 100+ methods put in 17 prefix groups and it works pretty good.
Thanks for that. No point wishing things were there that aren’t there and your workaround is probably better than the one I’ve been pursuing. It won’t be difficult for me to swap over now and it will avoid having all the optional parameters. Still I’ll file a request for the feature - it’s purely cosmetic to declutter the interface so I wouldn’t think it would be too difficult to bring in. The folders could have any old name you like, although in the above example it would make sense to name the folder texts - the actual methods could still be textExFile etc. Just nice to have 17 or so folders instead of 100+ methods.
I have just downloaded the Feedback app and made a feature request for expandable folders to hold methods and properties in custom classes. Please support it. I am not sure how to create a link to a Feedback Case but it is Case 44300 if anyone would like to help.