I have not done any coding for over 40 years, I wrote a lot of numerical simulation programs, in FORTRAN, in the 1960s. I also must have written some in BASIC. Now a Pensioner I am amusing myself with Xojo. My problem is to do with how best to structure a program/project/app. I am finding it very difficult to pass information and maintain control of the order of events. Could somebody point me in the direction of where I can learn how best to do this? Or even give me some tips. So far I have been able to place random coloured discs on a grid canvas and store these in an array, but I wish to use separate sub-routines (methods) to process the array and also place information graphically on the canvas and/or TextFields. I find a lot of information on the technical aspects of projects, but blessed little on structure and what is or is not mandatory. Somebody please help as my rate of progress has now ground to a near standstill.
That’s the fun of object-orientated programming: there is nothing mandatory. It’s up to you to decide, where to place things. And it’s always dependent on the complexity of an application.
Haven’t checked in a longer time if some of the examples are a bit more complicated. So the examples might be a good place to start.
First off… forget most if not all of what you learned from Fortran and previous incarnations of BASIC. Those are/were PROCEDURAL languages… Basically the relied on a top down/recursive program structure. That is you for the most part started on the first line, looped around in the middle, and finished at the last time.
Modern languages including XOJO are no like that at all. Xojo is an OBJECT ORIENTED, EVENT DRIVEN language. And as you mentioned the order of events can be important and sometime hard to understand.
XOJO consists of concepts that did not exist in less modern languages (hesitant to say old or ancient, as I am close to the same age group as you are 
)
But basically it boils down to 4 major things (the following is not all inclusive, just a quick high level approach)
Windows (forms)
Modules (code)
Objects
Classes (which oh by the way, can be objects)
A Window contains two major things.
Controls
Methods/Functions
These are probably the things you are most familar with… as it is “CODE”… Methods do something. Functions do something and return an “answer”. For the most part Methods and Functions inside a Window are PRIVATE to that window (for the most part, exceptions to everything). Controls in a window create and respond to EVENTS (such a a button press etc)
A Module contains
Methods/Functions
This methods and functions can be PRIVATE to the module, or PUBLIC and shared by any/all other windows, modules or objects in the program. This is also where you would define PUBLIC variables
Objects … well lets discuss that after you are more comfortable :), the same with Classes for now
Not sure the best way to describe them in a short forum response
But I bet someone else will add to this
I don’t know if you’re into video training at all but I have over 40 hours of Real Studio and Xojo training videos at http://www.bkeeney.com/XojoTraining/xojotraining.cgi. That’s roughly 120 separate videos and most of them with project files.
We have two complete series going from scratch and ending with complete applications. It might help a little with how to structure your app, how to pass things around, and so on.
A bunch of us will assist to the best of our abilities, but the first piece of advice is to forget a lot of what you already know about program structures. What you’ve learned in the past was based on linear (procedural) programming, so the programs had beginnings, middles, and endings with a clear flow at every stage.
Event driven programming can be similar to that, but object-oriented, event-driven apps are a different beast, and require a different mindset. You can’t and won’t control the flow, for the most part, so a lot of your code will be reactionary. (This button was pressed, so do this, or that menu was selected so do that.) It takes some getting used to, but invariably you will have that “ah ha!” moment where it comes into focus.
(Naturally, Dave beat me to this. Grrr )
I second Beatrix and Bob’s suggestions, but as you view the examples and videos, try to imagine that the data you’re dealing with are actual objects you could hold in your hand. Once you start thinking about them as “things” instead of just a series of steps, it becomes easier.
Start here: , Paul has put together some great PDFs on this subject. Also check out the Webinars available on the Xojo website and Bob’s video’s above are great. I would highly suggest going through the tutorials from start to finish.
I also do embedded micro development which is top down programming, as well as OOP development in Xojo. As Dave said they are different and require different thinking. Top down programming is very structured and you can tell what is going on as it is just like reading a book. Event driven programming is completely different. For right now don’t get hung up on the “right” way or how “should” this be done. The reason is this is a grayer area in OOP. Sure, there are definitely “wrong” way to do things but there are multiple different ways to get things done that will work, some more right than others. If you get hung up on “is this the right way to do this” you’ll get frustrated. There are certainly best practices and you’ll learn these over time.
Walking through the examples from start to finish in a structured project will really help.
The good part is this is a very active forum and quite lively at times, so help is just a post away.
Great news : you can program in Xojo almost as badly as before in Basic. Just do everything in the Open event, use GOTO (target lines are replaced by tags: ) and you can achieve a high level of non-structured programming 
Just joking, for the fun of seing some faint in horror.
In fact, when languages of the past where a list of ‘to do’, event driven programming is more like ‘do this when’. For instance the Action event of a button is ‘do this when Button1 is clicked’ and so on.
GOSUB has become methods and global variables have been replaced by arguments (although globals still exist but are not recommended).
The IDE and the graphical interface is what drives the program, and you must forget procedural programming.
What happens when I do that is the keyword 
A couple of thoughts to add to what everyone else has said. First, think of it this way: the “structure” of the program is written for you, behind the scenes, by Xojo. It really produces a lot of code for you. What’s left for you is to just “fill in the blanks” and focus on responding to user input. That’s what events are - the user did something, what will you do in response? Second, you’re jumping in the deep end with a canvas. You might want to play around with other controls first and get your feet under you. Then tackle the canvas.
Welcome to Xojo You will find this an extremely helpful community. All good advice above and it should keep you “amused” for quite a while.
Thank you for the advice, I will try and digest this. One issue, where I might have a misconception is access to variables. I am assuming that all variables existing in a Method/Class/Function defined as Public are available to code elsewhere in the App. Is this correct? My other struggle is that I find that a Canvas or a TextField say, that clearly exists on the Window and is defined as Public is said not to exist when code to paint or send text to these is compiled. Clearly I am still on the bottom of the learning curve and need a lift.
Well, a lot of messages here before I spotted the new post. All excellent advice.
One way (and there are millions) to think about GUI and object based coding is to consider that everything lives inside a massive
WHILE…WEND construct.
In a program with a single window,
The program starts, and displays a window.
While application isn’t closed … wait for a variable of some kind to change… react to it.
end
close the program.
On the window, and in the code of the window, all the controls that you put on a window will be created ‘for you’
They all have names.
And in the sense you imagine, they are all available within code that lives on the window.
Controls all have events: subroutines which are called when something happens.
Eg a button has a subroutine that is called when it is clicked.
A text field has a named subroutine that is called when it changes.
(These things were probably easier to spot in REALBasic than Xojo, because in RB the events all ‘existed’ but were empty.
In Xojo you kinda have to know that an event is possible, then ask for it to be added.)
The video training will explain this much better than text can of course.
The clicked event of the button can talk to the text property of the text field like this:
<button1_clicked event>
textfield1.text = “So thats how it happens”
If you have two windows, you can’t quite so easily talk to the textfield1 control.
It isn’t unique in the program, for a number of reasons.
Later on, you will find that you need references to the various windows stored somewhere.
Then you will be able to say things like PrefsWindow.textfield1.text =“Ah… so THERE you are”
Another thing is: in the procedural type languages you spend on average say 20% in designing the interface and 80% in controlling the program flow and logic. You can forget that in Xojo. With Windows, OSX and other GUI’s you spend (my humble opinion) 50% on designing the interface (and re-designing) and the rest of your time on logic and database access.
Separate the logic from the user interface, i.e. do not place the logic in the Action event of the interface objects… put it in a (global) method and access that method from within the Action event. If you have to rethink the interface (and you will) and remove or change some elements you have to copy/paste the code.
[quote=54311:@Roger Davies]Thank you for the advice, I will try and digest this. One issue, where I might have a misconception is access to variables. I am assuming that all variables existing in a Method/Class/Function defined as Public are available to code elsewhere in the App. Is this correct?
[/quote]
Not necessarily. Can you give an example? Variables defined in a Method or Function are not Public. Properties of a Class are available using an Instance of that class, not from the class directly.
It depends on where that code is. Again, a more concrete example would help us answer that. You may need to include the window name or an instance of the window, depending on how you’re set up.
The User Guide (book 1 or 2?) has a section on Scope that might help you understand how to refer to variables better.
Thank you Tim. I have read through the User Guide and attempted a number of the examples. Clearly I am struggling with a number of the concepts that are new too me and probably bread and butter to you. Probably the best advice will turn out to be “forget what you know from 40 odd years ago”. I will struggle further and attempt to look at the possibilities with fresh eyes. If still stuck I will be more specific with my questions.
HIGHLY recommended. I had a 2 year subscription to the BKeeney videos as I made the transition from Visual Basic to Real Basic a few years ago.
One more thought: Have you worked through the Tutorial yet? It builds an app step by step.