This may seem like a joke, but I am absolutely serious.
The are some complexities with my software that may require a “stepped” level approach for the User. That is, when the app is first started it begins at the lower level and then the User can opt in for more functionality via a selection in an options window, ie. [i][Beginner], [Intermediate], [Expert],
Not a new concept as [i] - but what are your experiences? Is it worthwhile, because most users may never bother to explore extra options or functionality.
I may well have a case of “Adding Extra Features” upon unnecessary features without possibly ever deploying my software.
I use a two layout design for our Producer’s Edition software that offers the “Drag, Drop, and the Monkey flips the switch” methodology as well as an “expose everything for advanced users” option. It’s worked well since 2004.
Actually, I’d forgotten that I posted this thread - it was a very late night after many hours coding, followed by a few beers The thought came to mind when thinking about what may be required for the UI - near the end.
My app only has one main layout/window. I guess I could make certain functions not visible, then have the user choose their level via the options window - which I haven’t completed.
I’ve found that User Error Detection is taking the longest time.
The easiest way to do that might be to subclass the controls, then have each subclass check a central property located in Module or even the Window. Each control would have a user level and would hide itself if it’s user level is above the general setting. After that, it’s just a matter of setting properties.
Of course, if you have to shift controls around based on what’s visible, this won’t work so well.
Well I have to show my ignorance and say that I really don’t understand subclassing.
I’ve read about it but cannot grasp the concept, so have gone back to my old inefficient ways. Can you, or someone point me to a good example - a worked example - not just the perfunctory notes in the LR.
Play with it. Start this way: create a new class, MyButton and set its super to Pushbutton. You can now override its behavior by filing in its events.
For example, implement the Open event and insert code to add 5 pixels to its own height if the platform is Linux or Windows. This is an easy way to create a button that looks good on any platform. Then create a custom event called Open and do something like this:
Event Open()
// Setup code like this
if TargetWindows or TargetLinux then
Height = Height + 5
end if
RaiseEvent Open()
Once you start to use subclasses, you will discover all kinds of ways to make your code easier to implement, understand, and manage.
It’s from 2004 but the concepts are still valid. The code is Java and can be easily converted to Xojo. When your code gets more complex the patterns make a huge difference.
I acknowledge that I know little about OOP, classes, event driven programming etc. I have done some reading and will do more if I pursue software programming further. I do remember in the past creating Type/End Type. My limited experience is based on procedural languages. It’s a good thing I don’t develop software as a profession.
I started using Xojo about 18 months ago and my program has evolved with my learning. If I was to start again, I would certainly do it differently.
Nevertheless, kudos to Xojo, in that whilst still using basic procedural methodology, I’ve been able to create a software solution way beyond anything I’ve created in the past.
It’s not finished yet, and because of my “spaghetti code” things are becoming a bit difficult. Fortunately I’ve written comments in the code along the way and have also kept written notes.
Rather than a global setting, on certain pages that need more complicated features we typically add a “More” or “Advanced” button.
This way they choose when they need to see more options,
It inspires curiosity on a section to section basis,
And you can remember their preference only for the specific sections they use this for.