Zugg Software :: View topic - [2.21] Changes to variable type don't take effect until the variable is changed

Posted: Sat Mar 29, 2008 11:43 pm

Procedure:

1) Create a variable "test" as an integer-type, with a value of "two".
2) Do #say @test to verify that it outputs '0'.
3) Change the type to auto-type (don't modify the variable just change the type and hit save).
4) Do #say @test to verify that changing the type didn't change the output. It still shows '0'.
5) Modify the contents of "test" by deleting a letter and then adding the letter back to allow it to be saved again.
6) Do #say @test and verify you now see "two".

Changing the variable type should cause it to display as "two", you shouldn't have to modify the actual contents to accomplish this.

Posted: Sun Mar 30, 2008 1:13 am

Reed, when a value is saved as an integer value of 0, how is CMUD supposed to know that it should also be saved as a string value of "two"? The value is not saved as a sting and then converted to a integer when you use the variable. The value is saved as an integer in the variable, and the original string is destroyed, lost in the process. If you change the valriable type, the value -saved- is going to be changed to the appropriate type, not the value of the original string.

Posted: Sun Mar 30, 2008 7:59 am

hogarius, I have no idea what you are trying to explain, but I think you totally missed what I was trying to get across with this bug report. If you try out the instructions perhaps you'll see what I'm referring to. The value doesn't get lost or destroyed, it's still sitting there same as it was when I put it in. This post is about how the typing doesn't take effect (when you change it) until you change the variable itself.

Posted: Sun Mar 30, 2008 10:40 am

I thought this might be an issue specifically related to autotype, but it's not. You can change the type to string and it'll still display 0 until you edit the value.

Hogarius: the issue isn't that it displays 0, it's that it continues to display 0 rather than changing when the type is changing. The string in question could be anything and the bug would still be present.

Posted: Sun Mar 30, 2008 4:24 pm

I'm going to try a step-by-step runthrough, with some comments along the way, so I and you can see what I am talking about. I'll using the Package Editor GUI to set up the variables.

1. Create a new blank session and open it offline.

2. Open the Package Editor.

3. Pull down the "New" menu, and select "New Variable".

4. Type "test" (no quotes) in the name field.

5. Select "Integer" in the "Type:" pull-down list.

6. Click the "Save" button. Note that the variable "test" is created in the left column, and the "Value:" field remains empty.

7. I'll now populate the value by typing "two" (no quotes) in the value field.

8. Click the "Save" button again. The "Value:" field continues to show "two" (no quotes).

--I'm a little surprised at this. How can "two" be saved as an integer, without being changed to an integer value? When I saved the value, shouldn't the value have changed from "two" to 0 immediately?

--Perhaps it's a settings editor refresh issue. Maybe if I create a new variable, and then display @test again, the value will show what I would expect (0, not the string "two").

9. Pull down the "New" menu, and select "New Variable".

10. Type "Beep" (no quotes) in the "Name:" field.

11. Leave the "Type:" pulldown set at "AutoType".

12. Click the "Save" button. Note that the variable "Beep" is created in the left column, and the "Value:" field remains empty.

--Now, let's check back on the value of the variable @test.

13. Click on "test" in the left column of the Package editor.

14. Note that the "Type:" field for @test still shows as "Integer", and the "Value:" field still shows the value "two" (no quotes).

--This surprises me more. Again, I would have expected the value to be shown as an integer, which would be 0 in this case, since the value was originally input as a string and would have been converted to an integer.

--What if I close the Package Editor, and then open it again?

15. Click the red "X" in the upper right corner of the Package Editor window to close it.

16. Click on the "Settings" button in the toolbar to show the Package Editor again.

17. Click on the "test" variable in the left column to show the details of the variable.

18. Note that the "Value:" field of the variable test still shows as "two" (no quotes).

--Again, I am surprised. The string "two" is not an integer value.

So, apparently the value assigned to a variable remains in that variable, even if that original value is not the same type of value as the type set for that value. I would then conclude that the correct value for the variable, according to the type set for the variable, is computed each time the value of the variable is requested by a script.

In that case, Reed and Fang, your questions are valid. But retaining the string value of "two" in a integer-type value is not what I would have expected of CMUD.

Posted: Sun Mar 30, 2008 6:59 pm

I think that we have a case of two separate bugs here? or does Cmud just use the varible type to determine how to parse the value stored in the varible, and not how to store it?

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

I believe that is correct, wyrm.

Posted: Sun Mar 30, 2008 11:11 pm

I let Zugg comment on Hogarius's item, but I don't necessarily see that as a bug. I don't think I'd want cmud switching around my values based on the type like you are saying it should do.

Posted: Mon Mar 31, 2008 2:57 am

I don't think my observation is necessarily a bug, and I can accept CMUD saving a string in a integer variable and returning the appropriate integer value for the variable as required. I should break that discussion off in a separate thread, but I'm a little too tired at the present to do that right now.

I would suggest further discussion in this thread address Reed's observations and comments as if I had never said anything. : ) Please don't delete my comments just yet, however!

Posted: Mon Mar 31, 2008 3:45 am

This was brought up by MrCheviot ages ago. It's not recompiling until a change has been made, and that can mess things up. In fact, here is the post:

Recompile on variable type change

Sigh. I see it as a bug, plain and simple. I shouldn't have to change a variable to make it accept the new variable type... :\

Charneus

Posted: Tue Apr 01, 2008 5:45 pm