WinPlaceChild Question

[MrLeadFoot]

Does the WinPlaceChild function in latest version of WinBatch support variables for the window coordinates like WinPlaceSet does?

Thank you.

[td]

I am not sure what exactly you are asking but the documentation for WinPlaceChild states, "This function is like WinPlace, but places a child window." So WinPlaceChild's parameters are parallel to WinPlace but not WinPlaceSet. If you think a little about the different functionality of WinPlaceSet versus WinPlace you can understand why that might be the case.

[MrLeadFoot]

Thank you for the reply.

To clarify, in the version of WinBatch I have the syntax for WinPlaceSet allows the insertion of a variable for the windows coordinates, but both WinPlace and WinPlaceChild do not. I understand the difference between WinPlace and WinPlaceSet, and was disappointed there was no "WinPlaceChildSet" function in my version. In lieu that, I was hoping that at some point the WinPlaceChild function would be "revamped" allow WinPlaceChild to use variables for the windows coordinates.

Examples:

This works:

Code Select Expand

Coordinates="268 0 1000 949"
WinPlaceSet(@Normal,"ParentWindow", Coordinates)
This doesn't:

Code Select Expand

ChildCoordinates="0,0,695,674"
WinPlaceChild(ChildCoordinates, "ParentWindow", "ChildWindow")
The only way WinPlaceChild works is if the coordinates are "hard-coded" into the function, like this:

Code Select Expand

WinPlaceChild(0,0,695,674, "ParentWindow", "ChildWindow")
Of course, I would be just as happy if there is a new child-window-placing function such as my previously-alluded to WinPlaceChildSet. If there is another function for child windows that supports coordinates substitution like WinPlaceSet does for parent windows, or even a workaround that allows me to achieve this, I am all ears.

Thanks again.

[MrLeadFoot]

Wait a minute, it looks like WinPlace and WinPlaceChild are outliers in a way, as far as syntax is concerned. I see now that you can indeed use variables in a different way. Normally in Winbatch, you use CoordinatesVariable without quotes and "%CoordinatesVariable%" within quotes. In the case of WinPlace and WinPlaceChild, you need to use %CoordinatesVariable% WITHOUT quotes. Now that I finally see that over all these years, I can see that I can make do without the newest version.

That said, I would still like to know if the newest version has a new child window function or WinPlaceChild accepts "normal" WinBatch variable conventions because if it does, upgrading would help me not have to remember little syntax convention differences between functions, if that makes sense.

As always, thank you again.

[snowsnowsnow]

I doubt there is any version issue here.  The function(s) is/are what it/they is/are.

You just have to get used to doing what you do for those functions that take the position arguments as separate arguments - which is to, as you note, use %var% instead of just var.  That's what I do and it is what you should do.

I'm not sure where you got the idea that you only use % substitution inside of quotes.  In fact, that's probably the one place where you should NOT use it.

Except that I sometimes use "%Param1%" if I want an empty string when Param1 is not defined.  It saves an explicit call to IsDefined() (or checking Param0).  But I am aware that I am cheating when I do it.

Also, you could do:

lst = "1 2 3 4"
FunctionTaking4SeparateArgs(ItemExtract(1,lst," "),ItemExtract(2,lst," "),ItemExtract(3,lst," "),ItemExtract(4,lst," "))

If you don't like using % substitution.

[MrLeadFoot]

Thanks for the reply.

Yes, I guess a function's syntax shouldn't get changed in newer versions because then scripts that were previously created in a previous version using that version's syntax would break when one updates to a newer version. It's just odd that one set of similar functions, such as the case with WinPlace and WinPlaceSet, use different syntax conventions in that one requires quotes and won't work with them, and the other doesn't work with quotes.

And, one of the reasons I never knew you could use substitution (albeit without quotes) with WinPlaceChild is because the Help didn't say as much for either WinPlace or WinPlaceChild, even though I tried Variable and "%Variable%" (which work with WinPlaceSet), and even tried creative variations of such. That said, when td pointed to the Help (which I looked at many, many times ove the years trying to figure out why substitution wasn't working with this function) this time I looked more closely at every other single function linked to in the help topic and happened to notice that the example for WinPosition showed that weird % substitution (without quotes).

FWIW, when I first started using WinBatch in 1994, I was taught to use % substituion within quotes with things like:

Code Select Expand

localdir=DirHome()
destination="E:\targetdir\"
FileCopy("%localdir%filename.txt","%destination%filename.txt",@false)
and

Code Select Expand

Message("FileCopy Completed", "The file was copied from:%@crlf%%@crlf%%localdir%%@crlf%%@crlf%to%@crlf%%@crlf%%destination%")
...although I later began using StrCat when there's a possibility that the substitution might exceed the 256 character string length limit, and sometimes to help the code not look so unwieldly.

Come to think of it, I don't think I've ever come across % substituion without quotes in 30 years of using WinBatch (not to say it might be documented elsewhere, but I obviously never encountered it). Like they say, you learn something new every day!

[kdmoyers]

This was a key discovery for me: How *rarely* substitution is actually needed. 

Speaking for myself, I remember my wbt coding started going much better after I got it. Now only a tenth of my programs have any substitution at all.

These days, I would write that FileCopy command above like this:
FileCopy( localdir:"filename.txt", destination:"filename.txt", @false )

After I got used to it, my code seemed easier to read too.

[snowsnowsnow]

Agreed.  But it makes sense - given that WinBatch can be seen as an extension of ordinary DOS/WindowsNT batch language.  I came to WB from ordinary batch (many many many years ago), where %var% was the only way to do it, so naturally started doing the same in WB.  Like you, it took me a while to realize it was unnecessary and that the language supported using variables "normally" (i.e., the way they are accessed in most "real" languages, like Fortran or C).

The only real reasons for using it are:

1) To accomplish tricky things like here in this thread, where the syntax requires it.  Also, to accomplish the equivalent of "pointers" in other languages or delayed evaluation of function arguments (I have a few UDSes that use this sort of thing, such as my usdAssign() and friends). Yes, I know that the WB language now has "pointers" as a supported feature, but I never really saw the point in it, so I never took the time to learn about it.

2) As a Q&D when you're too lazy to use StrCat() like you're supposed to.  Yes, the introduction of ":" as a alternative for StrCat() makes this less relevant, but, again, I never really cottoned to the ":" thing (Readers with good memories will remember that I actually developed a system for converting code that uses ":" back to using StrCat())

3) As a Q&D for making unset variables evaluate to empty strings rather than triggering an error.  Example: "%Param1%" rather than Param1 (which triggers error if unset).

[spl]

I agree to agree. The point that one can use %var% in a variable expression is probably only dependent upon ultimate execution. I used, and perhaps will always use substitutions for sql

zip = '27619'
and you can code
sql= "Select zip from zips where zip = %zip%;"
or
sql= "Select zip from zips where zip = '":zip:"';"
or
an old school strcat() sql = strcat( blah blah blah )

Either way, it is up to the coder. The issue being how readable would excessive substitution confound another who was passed the code.