Window title Separate by "x" oddity

[JRL]

Using Macro Scheduler version 9.1.02
I've discovered that I can't use Separate> or Position> to acquire the location of an "x" if it comes from a window title and is surrounded by numbers. I.e. If a window title contains the text "22x33", Separating the title text using an "x" as the delimiter will not divide the text into two parts. If I set a variable to "22x33" and separate using "x" as the delimiter It works just fine.

After more testing it turns out that a number in the name anywhere will prevent separating by "x".

Try this:

1) Open Notepad and save a file with a name "test 1234 this x.txt"

2) Run the following script.

3) Make the notepad window the focused window.

4) With a delimiter of lower case x nothing will happen in the dialog box.

5) Close the script

6) Edit the script changing the separate delimiter to lower case t

7) Run the script

8) Make the notepad window the focused window.

9) Observe the results of separating by something other than lower case x.

Thanks to anyone who figures this out or tells me what I'm doing wrong...

Code: Select all

Dialog>Dialog1
   Caption=Dialog1
   Width=445
   Height=250
   Top=0
   Left=0
   Button=Ok,176,160,75,25,3
   Label=msLabel1,24,8
   Label=msLabel2,24,40
EndDialog>Dialog1

Show>dialog1
Label>start
GetDialogAction>dialog1,r1
If>r1=3,EOF
If>r1=2,EOF
GetActiveWindow>WinName,X,Y

//Change the delimiter in the next line//////////////
Separate>%WinName%,x,name
//Separate>%WinName%,t,name

If>%name_count%>1
    Let>dialog1.mslabel1=%WinName%
	Let>k=0
	Let>dialog1.mslabel2=
	Repeat>k
	  add>k,1
	  Let>value=name_%k%
	  Concat>dialog1.mslabel2,%value%%CRLF%
	Until>k,%name_count%
EndIf
Wait>0.01
Goto>start
Label>EOF

[Me_again]

I couldn't figure out how to test your dialog, but I think I can offer you a solution (which you would be justified in calling a workaround) to this obscure problem based on my testing.

I have found that if you use X and Y in:

GetActiveWindow>WinName,X,Y

you can't use X, x, Y, y to separate WinName. If you change that to:

GetActiveWindow>WinName,A,B

I think you'll find that separating by x (or y) will work. (But separating by a and b won't.)

[JRL]

You got it. I'm an idiot.

I set x to a number using GetActiveWindow> then couldn't separate by "x" because its now a variable with a value.

Thanks,

[Me_again]

There ya go, a logical explanation derived from an empirical result

I think VAREXPLICIT should fix it too.

[pgriffin]

I agree that this was tough one to spot, Good job!

This is another good reason to ALWAYS use longer variable names.

Use something like GetActiveWindow>ActiveWindow,X_Pos,Y_Pos

Single letter variables are trouble...

[jpuziano]

Single letter variables are trouble...

Truer words were never spoken. I learned about this the hard way when I created some macros that used single letter variable names and assigned various single character text strings to them in a text processing macro. The results were completely unexpected (to me at the time) and I reported it as a bug in this old post: A Christmas ConCat Bug (ver 7.5)

To quote Marcus from his explanation in that post, "everything is seen as a variable unless you turn VAR_EXPLICIT on. It keeps resolving."

I would now say, variables keep resolving, to a point. Consider this code:

Code: Select all

Let>a=b
Let>b=c
Let>c=d
ConCat>a,b
MDL>a

What do you think will be displayed? If variables kept resolving "for as long as they possible could", you might expect "dd" to be displayed. Nope, it displays "cc".

To me, that means when the ConCat> command runs, this is what happens:

• - First Parameter: does a variable named "a" exist?
  - Resolve Once: yes so substitute in its value, in this case "b"
  - does a variable named "b" exist?
  - Resolve Twice: yes so substitute in its value, in this case "c"
  - Stop there, we've resolved 2 deep for parameter 1
  - the value of variable "a" is now seen as the letter "c"
  
  - Second Parameter: does a variable named "b" exist?
  - Resolve Once: yes so substitute in its value, in this case "c"
  - Stop there, we've resolved 1 deep for parameter 2
  - the value of variable "b" is now seen as the letter "c"
  
  - concatenating them together, we get "cc"
  - so the new value now stored in variable "a" is "cc"
  - try it and you'll see that "cc" is what is displayed

The first parameter resolves twice and the second only once. I don't know why ConCat> was designed this way but using single letter variable names and assigning single characters to them as you pull apart and parse strings can drive you crazy and give unpredictable results. I am fairly sure that the VAREXPLICIT System Variable was created to mitigate this unpredictability by letting you decide *which* variable names you want it to resolve... by surrounding them with % signs as in %a% but again, how many times will that %a% resolve? Does it depend on whether its in the first or second parameter of a command as it does in the ConCat> example above?

I find I don't use VAREXPLICIT much. What I find works best is to use long, descriptive and unique variable names for everything. Let's try that example again:

Code: Select all

Let>a_var=b
Let>b_var=c
Let>c_var=d
ConCat>a_var,b_var
MDL>a_var

What do you think would be displayed? If you said "bc" you're right. This is exactly what I would expect from the description of the command and multiple levels of variable resolution have not complicated things.

Sorry for going on about this... but I consider this one of the Top 10 Best Macro Script Coding Habits to observe. And besides removing any unexpected/unwanted levels of variable resolution, you get used to using nice descriptive names for your variables which if picked properly, can make the code easier to read and modify later.

Take care
_________________
jpuziano

P.S. If anyone else has a helpful Macro Script Coding Habit they think belongs in the Top Ten, please post your thoughts. Maybe we can get a full 10 if we all chip in.