I'm sorry if this is the wrong place for this post but it looked like the best option.
Ever since build 5636 I seem to have an issue with my scripts not reading xml files correctly. Is there some way to revert back to build 5616?
Build 5636 issue
Moderators: Lavish Software Team, Moderators
Yes, you can revert, but if you think there is a bug, I would definitely need more information in order to track it down. There are no other reports of issues with any type of XML file, and ISBoxer certainly still works (and makes use of both settings XML and GUI XML files).
http://www.lavishsoft.com/innerspace/archives
http://www.lavishsoft.com/innerspace/archives
I think I've isolated the issue.
For UI selections, ItemByValue used to be an alias for (and automatically used instead of) the actual ItemByText. So, if you are using .xml that has ItemByValue when it should be ItemByText, it won't work anymore.
But, I don't see any changes after 5616 that references this.
For UI selections, ItemByValue used to be an alias for (and automatically used instead of) the actual ItemByText. So, if you are using .xml that has ItemByValue when it should be ItemByText, it won't work anymore.
But, I don't see any changes after 5616 that references this.
ItemByValue was never an alias for ItemByText nor automatically used instead of it, and was never documented as such. It couldn't logically automatically use that, because the two were not even expected to be compatible types, with the value being int and the text being a string.
The change that was made is as follows:
lguilistboxitem.Value is now a string instead of an int.
(Likewise, ItemByValue now accepts a string to compare instead of an int to compare)
* If you were using it as a pure int, it should still work as it did before.
* If you were putting a string as the value, it would have likely always been 0 (as in ${Int[xyz]} is 0) and ItemByValue[xyz] would have always returned the first item with the particular integer value, being 0. (Noting that any number of items may have the same Value); with the new build the value would be xyz instead of 0.
* If you never explicitly filled in a value, the value was 0, and ItemByValue[xyz] would have always returned the first item with the value 0. With the new build the default value is technically an empty string instead of 0.
So, there may be interesting new behavior because of this change, but if there is it's more likely due to always having had faulty ItemByValue usage..
The change that was made is as follows:
lguilistboxitem.Value is now a string instead of an int.
(Likewise, ItemByValue now accepts a string to compare instead of an int to compare)
* If you were using it as a pure int, it should still work as it did before.
* If you were putting a string as the value, it would have likely always been 0 (as in ${Int[xyz]} is 0) and ItemByValue[xyz] would have always returned the first item with the particular integer value, being 0. (Noting that any number of items may have the same Value); with the new build the value would be xyz instead of 0.
* If you never explicitly filled in a value, the value was 0, and ItemByValue[xyz] would have always returned the first item with the value 0. With the new build the default value is technically an empty string instead of 0.
So, there may be interesting new behavior because of this change, but if there is it's more likely due to always having had faulty ItemByValue usage..