>Hi James,
>
>Couple things:
>
>AddProperty to _SCREEN should not be done in the form, because you can only add a property once. If you have multiple top level forms the second one to execute the AddProperty will get an error. Your main prg should perform the AddProperty at the beginning and set it to .NULL.
I figured as much. My initial "FOR EACH oForm IN APPLICATION.FORMS" routine would also return bad info if multiple TLFs were used.
>If you are basing your forms on a single "base" class, you could put code in the Activate event of the form:
>
>
>IF this.ShowWindow = 2
> _SCREEN.TopForm = this
>ENDIF
>
>
>and in the Destroy (and possibly in the Deactivate):
>
>IF this.ShowWindow = 2
> _SCREEN.TopForm = .NULL.
>ENDIF
>
A resounding "Dhoh!" I would've forgotten the dangling reference - good caveat.
>
>This code would prevent the need to keep a stack. The Application.Forms collection is just as good as a stack.
>
>It also looks like you have your own global application object oApp. Rather than adding it to _SCREEN, why not add the property (using the Class Designer, rather than the AddProperty method) to your application object?
>
>SET OPINION ON < g >
>The AddProperty method is a work around approach to mistakes in design in my opinion. Except for special circumstances (such as adding something to _SCREEN for example), I always add the property to the proper class in the designer.
>SET OPINION OFF
Yup. I kinda screwed up my reply and posted both a draft and a final version of the same reply back
. I agree that the class builder would be the place to pop in the new property, vice adding it to the _SCREEN. But hey, it never hurts to have more than one path up the mountain, right?
BTW, thanks for the comments. I'm getting smarterer by the minute <g>.
>
>Hope this helps
>
>Rick
>
>>So, in summary,
>>2. I could build my own 'stack' with an array, but unless I'm using it for something else as well, there's not much point.
>>3. I could DO form topform name oApp.topform linked; but I'd need to name all of my topforms uniformly ('topform')
>>4. Using ADDPROPERTY() to the TL form, I can access the TL's properties in a class.
>>
>>5. Possible AHA! Since I'll most likely have to write a formTL_dr class to handle my dynamic resizing, I could add the ADDPROP code to the TL class,
>>or just add it as a property in the designer. Hmm.... Thanks everybody!
>>
>>
>>>Sergey,
>>>
>>>Thanks for your prompt reply. I'll try this out. But I thought _SCREEN was only available to apps designed with SHOWWINDOW=0 ?
>>>Also, if _SCREEN.width returned the incorrect value, wouldn't _SCREEN.OTlfName.width give me the same?
>>>Give me a sec, and I'll try it.
>>>
>>>>James,
>>>>
>>>>What about adding following code to the init of top level form?
>>>>
>>>>_SCREEN.AddProperty("oTFLName", THISFORM)
>>>>
>>>>After that you can reference it as _SCREEN.oTflName
>>>>
>>>>>Hope someone can help me here. I know enough to be dangerous, as they say. Here's my question:
>>>>>
>>>>>I'm taking my first stab at a top level form application, rather than the "In Screen (Default)" type. I'm playing around with dynamically resizing (the file examples and the Jan 99 issue of FoxproAdvisor were very helpful, thanks). I'm trying to find the right command for determining the name of the top level form, from within the application. I tried using _SCREEN, _VFP, and APPLICATION, but no joy. So far, I'm able to get it by using the following code:
>>>>>
>>>>>>>>>>FOR EACH oForm IN APPLICATION.FORMS
>>>>> IF oForm.ShowWindow = 2
>>>>> oTLFName=oForm
>>>>> EXIT
>>>>> ENDIF
>>>>>ENDFOR
>>>>>
>>>>>IF TYPE("oTLFName")="O"
>>>>> * I can now refer to it's properties, i.e., oTLFName.Height
>>>>>ELSE
>>>>> * ShowWindow property is set to either 0 or 1
>>>>>ENDIF
>>>>>>>>>>
>>>>>Is there a cleaner method of accessing TLF properties? I know that I could simply hard code the name, but I would like to create a class from this, if feasible. Thanks in advance...
