If you are looking to make your window declarations common, and introduce a TextField in special cases, I suggest you use winclasses instead.
What you are attempting to accomplish is typically done with winclasses. Put all the common, generic objects / methods in a base class. Derive all HTML window declarations from the base class, and add objects or override methods as needed in the actual declaration.
Attempting to identify windows and use different .inc paths at runtime can't be done, to my knowledge. With winclasses and functions like GetParent(), you can make runtime decisions.
I'm having a hard time coming up with a reason why you'd be doing this. It might help me and others to understand better if you provide a brief explanation of "why" or an example.
The solution will depend on precisely what stage of runtime you have the information (path and/or filename, I'm assuming) available to be able to "use" the file of window decs.
If the info is available at some point during the execution/loading of the actual frame file (before or during DefaultTestPlanEnter, DefaultScriptEnter, or DefaultTestcaseEnter) then I might have a solution for you. I've done something similar in regard to values for global variables during script development. But I don't want to go into the details if this isn't the case.
If the info isn't available until somewhere within a testcase then I don't have any ideas off the top of my head.
[QUOTE]Originally posted by pcostigan:
[B]I'm having a hard time coming up with a reason why you'd be doing this. It might help me and others to understand better if you provide a brief explanation of "why" or an example.
Actually it can be a very handy thing to do. In the perl programming language it is possible to either include files at runtime using their "require" command, or at compile time via a "use" command similar to Silk.
In my perl programming activites, I have found the require command to be a lifesaver on a few occcassions. With Silk I sometimes have to jump through some very high hoops to get around not having a "require" command equivalent.
In the area of window declarations, it would be really nice if I could redefine the window cmd command line invocation on the fly using a require command. Right now I do the following workaround:
I have a batch file called "temp.bat" and for the cmd invoke line I invoke temp.bat. Then I create temp.bat on the fly and write to it whatever command line I want to use. This can be useful when trying to test a command with a variety of switches which will give the same opening window in each case.
Clumsy, but it works. A require command would be a bit more robust.
The winclass idea described by the previous poster sounds like an interesting alternative.
Charles F. Radley - CSQE
[This message has been edited by cradley (edited 12-28-2000).]