Passing variables between forms

[thegame8311]

In the parent form is this:

Do Form Add with T_Name to Team_Name

In the form's init that is called

LPARAMETERS Team_Name

IF NOT USED("LivePlayers")
	USE LivePlayers IN 0
ENDIF

IF NOT USED(Team_Name)
	USE (Team_Name) IN 0
ENDIF

Team_Name is the T_Name from the first name

For some reason I can't get the variable to stick on the form

the variable Team_Name has either .T. or .F.

so why is the variable not passing from the first form to the second form

 

[thegame8311]

ah event sequence order ok I see why so things are not available when I expect them to be. I thought that form init would come before the object init's, but since it does not that is why things don't appear when I expect. I have since fixed that issue per my understanding of event sequence

 

[EzLogic]

Remember LISA

Load
Init
Show
Active

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Olaf Doschke]

True, but only a starter - and saying nothing about form init vs form control init.

Remember SET EVENTTRACKING (ON, TO somefile) and SET EVENTLIST.

Also having a read on ALL events is very enlightening in what triggers them and how theyr Return value or executing NODEFAULT effects their behaviour.

Bye, Olaf.

 

[thegame8311]

so I can use the set eventtracking like a log of activities on a form?

 

[Olaf Doschke]

Well, yes, that is about eventtracking, it's a developer tool to track which events fire in what order. And you can limit it to the events of interest.

That's often easier to debug something without suspending code. In cases you need to debug activate/deactivate/focus events the debugger would also interfere, because it actually removes focus of the active form to itself.

And by the way:

1. Even more info about each line executed is logged via SET COVERAGE.

2. The callstack window in the debugger will also tell you what happend before getting to the point you are now in the trace window. You can switch to the previous methods leading here within the callstack window of the debugger.

Bye, Olaf.

 

[Dan Freeman]

Using EVENTTRACKING or COVERAGE here would be like driving an M-1 Abrams tank to the grocery store. The debugger, a far more important and useful tool to learn, should suffice.

 

[thegame8311]

Yeah I have used the debugger more and more, so that is useful, I will also try the set coverage, that will tell me alot about what is going on

 

[Olaf Doschke]

Dan is right, don't overdo.

Especially don't forget to remove these logging when compiling to EXE, because that logs cost performance. Both are developer debugging and analysis tools.

Bye, Olaf.

 

[thegame8311]

ok, but I will use them temporarily to see how they work