Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

StringReplace fails with semi-large strings?


  • Please log in to reply
8 replies to this topic
joelr
  • Members
  • 6 posts
  • Last active: Apr 06 2004 05:11 AM
  • Joined: 15 Mar 2004
Hi. I'm the one who posted that thing about SendInput - I gave up, and decided that it'd be better & more modular to use the code that's already been put into AHK. So, now my only problem is this - I have to pass a string (about 3 paragraphs) to my app via the command line. You can't send CRLF through the command line, so I encode it as something else, then in my script I do this:

StringReplace, clipboard, %4%, CRLF, `r`n, all

and I get this error msg:

"WARNING: This dynamically-built variable name is too long.

Info: %4%"

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Just remove the % symbols from around the 4. Since 4 is an input variable you don't need them. I've made this mistake myself countless times.

This is one of the drawbacks of allowing dynamic variables (which was done to support arrays): It's harder to catch syntax errors like this at load-time. So instead, you wind up with runtime problems.

I added the following to the error msg to make it clearer: If this variable was not intended to be dynamic, remove the % symbols from it.

joelr
  • Members
  • 6 posts
  • Last active: Apr 06 2004 05:11 AM
  • Joined: 15 Mar 2004
Hm, I guess I don't understand how variables are handled in this AHK language then... the help file says that any time you are *reading from* a variable (i.e. not setting it to something) you enclose it with % signs. That makes sense, because otherwise how would the StringReplace function tell the difference between the number 4 or the string 4 and the variable 4?

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Functions that take input or output variables never use % signs unless you specifically want them to by dynamically resolved, which is rare. This is for backward compatibility with AutoIt v2, and also because it does make typing easier.

In other words, you can't do a StringReplace like this on a literal string (nor would there ever be a need to):

StringReplace, OutputVar, some literal text, some, no

So that's why the name of an input variable is always expected in place of "some literal text" in the above example. I know it takes some getting used to.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
As I put in the edited post above:

I added the following to the error msg to make it clearer: If this variable was not intended to be dynamic, remove the % symbols from it.

This might help alleviate confusion in the future.

joelr
  • Members
  • 6 posts
  • Last active: Apr 06 2004 05:11 AM
  • Joined: 15 Mar 2004
[quote name="cmallett"]Functions that take input or output variables never use % signs unless you specifically want them to by dynamically resolved, which is rare.

Hm... I can understand that for output variables, because you can't output to any literal expression, but input variables can be literals in every language I've ever used.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Yeah, it takes some getting used to, I know it's weird.

But when you think about it, you're not giving up anything. There would never be a need to have a literal string in place of an input variable because in those cases you always know what the answer would be before you ran the command. In other words, there would be no need to run the command at all, just assign the known-answer to the output variable and the same effect is achieved. For example:

StringReplace, OutputVar, some literal text, some, no

(were it allowed) would be equivalent to:

OutputVar = no literal text

Edit: I think I'm going to update all the commands that take input vars to emphasize this point, since it's a very common source of confusion.

joelr
  • Members
  • 6 posts
  • Last active: Apr 06 2004 05:11 AM
  • Joined: 15 Mar 2004

There would never be a need to have a literal string in place of an input variable because in those cases you always know what the answer would be before you ran the command. In other words, there would be no need to run the command at all, just assign the known-answer to the output variable and the same effect is achieved.


Hm, maybe I don't understand what an input variable is - is the title parameter not an input variable in the WinActivate function?

And if that's not considered an input variable, then what about an encrypting function for strings (say, before transmitting them) - wouldn't it make your code hard to read and hard to maintain if all of your literal strings for transmission had to be hard-coded in an encrypted form? It would also take about 10x longer to write any kind of code if you had to preprocess all literals manually rather than at runtime.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

is the title parameter not an input variable in the WinActivate function?


No, it's just a parameter. Most parameters are "normal", meaning that they consist of literal text, variable references, or a combination of the two, such as %ProgramFiles%\AutoHotkey\AutoHotkey.ini

Only those parameters that are clearly marked as variables in the documention are treated as though they had percent signs around them.

I don't follow what you said about encryption (perhaps it was just an example). But keep in mind that AHK operates this way mostly to stay compatible with AutoIt v2, which is one of primary reasons it was developed in the first place.

If you think there's a way to improve the syntax, perhaps you can give a specific example or two of something you'd like to do but that would be cumbersome or impossible the way AHK is now.