Tutorial: Macro Dialogs and Frames

[Mrugnak]

ok, I didnt noticed resetProperty() function, but still think that for many GM especially not programmers this will be issue. I hear a java programmer from you, not a macro designer no offense.

Heh none taken, but the function to check if a property was empty was requested by several non programmers who were having errors occur during macros

This is exactly it.

The problem stemmed from the fact that an "empty" Property makes string comparisons and manipulations and whatever go totally pear shaped, because it doesn't have any kind of string in it. A Null/empty value is basically a sort of number (close enough in this context) and computers get very very huffy if you try to ask them if the string "Weapon1Name=" is in a particular number. And then your macro errors out with another cryptic error message...

The difference between a Null property and a property with an empty string stored in it is a bit hidden from users (and even if we showed it, folks who don't have programming training would think we were crazy, basically), so a function had to be added to help the macro coders detect it and catch the problem. The difference is significant, however - a null property can use the default value in the right circumstances, whereas a property that's been "overwritten" with an empty string will NOT use the default value.

Changing the way isPropertyEmpty works is going to mess up all those people that needed it in the first place.

However, clearly documenting it, and perhaps adding a isPropertyValueEmpty() that behaves as expected might be a good plan

[Craig]

and perhaps adding a isPropertyValueEmpty() that behaves as expected might be a good plan

Ahh but here is the rub, what is expected for that function?
If the property is numeric then its always false, no such thing as an empty number.
String appears easie,r a zero length string is certainly empty.
But what about
" , " - it could be an empty list (as that is how some people create them) or a string that is not empty.
" ; " - like wise it could be an empty property list, or a string that is not empty.
It doesn't end there. In b49 the following strings could also in a sense be considered empty.
"[]", "[ ]", "{}", "{}".

The problem is one of context, any of the preceding strings could be considered as "empty" or non empty depending what context you are looking at them in. isPropertyValueEmpty() is not able to infer the context that the string would be used in, where as presumably the macro writer is able to, so could use if (listCount(foo) == 0) if(length(foo) == 0) or if(countStrProp(foo) == 0), well you get the idea.

[n3phrit]

String appears easie,r a zero length string is certainly empty.
But what about
" , " - it could be an empty list (as that is how some people create them) or a string that is not empty.
" ; " - like wise it could be an empty property list, or a string that is not empty.
It doesn't end there. In b49 the following strings could also in a sense be considered empty.
"[]", "[ ]", "{}", "{}".

I think that we should consider all property values as strings, thus your examples should be all non-empty values (even they can be JSON objects or lists or whatever). I dont know how parser works, but from user perspective, as long as I can edit the content of property, I will still see it as a string. Fact, that something within this string is internal MT object does not affect me. If it is properly formatted it will be resolved anyway. Property is still EDITABLE input dialog not internal data structure (like blob), that is why I think it should be taken as a string. With "" as empty value, but well we had this discussion earlier. And at the end it is not that important.

[Azhrei]

but from user perspective, as long as I can edit the content of property, I will still see it as a string. Fact, that something within this string is internal MT object does not affect me. If it is properly formatted it will be resolved anyway.

Heh-heh. You'd like Perl much more than you're going to like Javascript, then...

[Craig]

I dont know how parser works, but from user perspective, as long as I can edit the content of property, I will still see it as a string. Fact, that something within this string is internal MT object does not affect me. If it is properly formatted it will be resolved anyway. Property is still EDITABLE input dialog not internal data structure (like blob), that is why I think it should be taken as a string. With "" as empty value, but well we had this discussion earlier. And at the end it is not that important.

But from the users perspective you can edit the value of a property even if it is null. And from a macro perspective they are 2 very different things, and empty string does not get replaced by a default value but a null does. People have asked for a way to tell the difference between an empty property and a property with an empty value and that's what this function will allow them to do.

[Mrugnak]

but from user perspective, as long as I can edit the content of property, I will still see it as a string. Fact, that something within this string is internal MT object does not affect me. If it is properly formatted it will be resolved anyway.

Heh-heh. You'd like Perl much more than you're going to like Javascript, then...

Perl, where everything's a string! Even numbers! And lists! And hash tables! Even though they're busy being a number and a list and a hashtable, they're a string at the same time!

It's like magic.

It sounds really USEFUL... except when it really isn't. Gah.

[Azhrei]

Actually, I was thinking of Perl is in the undef statement and value. For example, an array such as

Code: Select all

@words = ("this", "is", undef, "a", "test");

Produces an array with 5 values. But what happens in a subroutine that tries to return $words[2]?

Perl is a typeless language, but it does support the idea of undef. And a Perl programmer without a good grasp of what that means is going to have a lot of problems! Perhaps not with a really simple script, but in anything significant it will be an issue.

But MT will eventually go to Javascript, so I guess the Perl reference was a non-sequitur. (Using the second definition, of course! )

[jfrazierjr]

but from user perspective, as long as I can edit the content of property, I will still see it as a string. Fact, that something within this string is internal MT object does not affect me. If it is properly formatted it will be resolved anyway.

Heh-heh. You'd like Perl much more than you're going to like Javascript, then...

Perl, where everything's a string! Even numbers! And lists! And hash tables! Even though they're busy being a number and a list and a hashtable, they're a string at the same time!

It's like magic.

It sounds really USEFUL... except when it really isn't. Gah.

I happen to love Perl's DWIMiery (thats Do What I Mean). No errors when trying to add a string and a number, it just concatenates. No spending extra typing time on every thing checking to see if it's a string or a number or whatever so you can convert to string. Why can't every language know that

Code: Select all

"2" + 2 = 4??? 

[Azhrei]

Why can't every language know that

Code: Select all

"2" + 2 = 4??? 

And why can't every language know that

Code: Select all

$x = "";
if ($x) { print "True\n"; } else { print "False\n"; }

should print False and

Code: Select all

$x = "0";
if ($x) { print "True\n"; } else { print "False\n"; }

should print False, but

Code: Select all

$x = "0.00";
if ($x) { print "True\n"; } else { print "False\n"; }

should print True?



But yes, Perl's typeless language is very useful. You just have to be careful how you use it.

I particularly like things such as print "@words\n"; that will interpolate the indexed array, but print "%words\n"; won't interpolate the hash array.

I teach both an Intro to Perl (five days) and Advanced Perl (four days) and all we do is scratch the surface! Yet there's enough covered in those two courses to make you proficient with Perl in a wide variety of application areas (graphics, database interaction, CGI programming, networking, sysadm tasks, etc).

Did you know that Randal Schwartz (author of the llama book) has a Perl class that lasts 3.5 weeks! Sheesh!

[Craig]

Why can't every language know that

Code: Select all

"2" + 2 = 4??? 

And why can't every language know that

Code: Select all

$x = "";
if ($x) { print "True\n"; } else { print "False\n"; }

should print False and

Code: Select all

$x = "0";
if ($x) { print "True\n"; } else { print "False\n"; }

should print False, but

Code: Select all

$x = "0.00";
if ($x) { print "True\n"; } else { print "False\n"; }

should print True?



But yes, Perl's typeless language is very useful. You just have to be careful how you use it.

For each of its uses it has its pains as well... Often the answer to how can I tell the difference between an A and a B is use a regular expression, ugh.

And don't get me started on people who want to use perl to manipulate binary files...

Having said all that, it is great for text processing.