Zugg Software :: View topic

Posted: Mon Oct 19, 2009 7:17 pm

1) start untitled, blank session
2) open PE
3) create new multi-state button, named test
4) add, sub-state one, script one, sub-state two, script two sub-state three, script three
5) save, click xml tab CTRL+A, CTRL+C
6) delete the button
7) click on untitled window, click xml tab click after </packages>, CTRL+V
8) save
9) click after </packages>, CTRL+V again
10) save, notice different order/format

what I'm getting is 2 buttons, first is a PUSH button "Three" with sub-states one and two, and a multi state button "Three" with sub-states one and two.

I believe that it is also possible to get this bug by EDITING a multi state button, i have a few multi-state buttons that i haven't messed with much since the button code changes. Last night i attempted to edit one and.... well the button blew up on me. I was setting the buttons variable from another script and instead of going to the corespoding button state it was going to... another state, copied xml imported and found this.

Posted: Mon Oct 19, 2009 10:12 pm

I'm not able to reproduce this problem in 3.10a. Here is the XML that I get from the multi-state button:

Posted: Mon Oct 19, 2009 11:17 pm

mkay, after creating the button my xml is:

Posted: Tue Oct 20, 2009 12:42 am

Ok just tried this on another machine, clean install never had cmud on it, same results. i'll keep playing with it to see if i can't figure somin out.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

I think this might be related to multistate anythings. I've noticed some multistate triggers that I have spent a while working on either disappear or the States get messed up. My AdvPrompt package in the package library might be able to help narrow it down, it contains a multistate trigger and a multistate button. neither of which import correctly.

Posted: Tue Oct 20, 2009 4:25 pm

Yeah, we need to pin this one down. I just ran the CMUD 3.10a release on a new computer. Here is the exact procedure I used:

1) Run CMUD
2) Close the Session window
3) Click the Settings button in toolbar
4) Copy the above XML from this forum post
5) Click on the "untitled" window (should already be selected)
6) Click on the XML tab
7) Click in the editor at the beginning of the line that says to position the cursor there
8) Press Ctrl-V to paste the XML
9) Click the Save button in toolbar

At this point, the Untitled window shows as collapsed with a + icon to the left. I clicked the + icon to expand it and saw a single button entry called "test" with a + button to the left. I clicked the + button to the left to expand it and saw three substates of the button "one", "three", and "two".

If I actually click on the test multistate button in the main window, the drop-down menu says "three", "one", "two".

So there *is* a bug with the order of states not being maintained correctly, and that bug has already been on my list for a while.

But I'm definitely not getting more than one button and I'm completely perplexed on how that could happen.

Posted: Tue Oct 20, 2009 5:40 pm

OH oh oh, sorry, when i pasted the xml in ONCE i got 1 button, when I pasted it in a SECOND time i got another button.. but different order, different states different all together, after CTRL+V for the 3 or 4th time the rest all seem to import the same. i'll see if i can't find anything else that might remotely help.

Posted: Tue Oct 20, 2009 8:05 pm

Editing XML directly like this can be tricky. I'm not sure I can necessarily call this a bug.

When you *replace* existing XML code with something similar, then you might run into problems because it's hard for CMUD to determine exactly what you are trying to do. The issue happens when the ID numbers in the XML don't necessarily match the existing ID values. With substates, CMUD doesn't really know how to use the "caption" or name of a button state to replace an existing state or not.

It's a common problem with the copy/paste system: when you paste XML, do you want 1) NEW settings to be created, or 2) EXISTING settings to be overwritten. Since overwriting existing settings can often be a problem causing lost code, CMUD usually defaults to creating new settings.

The *CORRECT* way to edit the XML that we are talking about here is to FIRST remove the existing Button XML, then click Save. Then Paste the XML Button code and click Save again. Don't just try to replace the existing button code by pasting a second time. Always remember to first remove the button code that you don't want and THEN add the new code.

The general rule of thumb is do *not* edit the XML tab directly. That was added as a very advanced feature, mostly for me to debug the XML import/export code. If you want to PASTE XML code, then the proper way is to right-click on the Tree View and select PASTE from the menu. Doing a Paste in this way calls some additional code to deal with the issue of creating new settings vs overwriting existing settings and handles the issue of duplicate setting names properly. Do this instead of pasting directly into the XML tab.

Posted: Tue Oct 20, 2009 8:32 pm

AHhh, can't say i've had a lot of problems with copy and paste, but what your saying makes sense.

So back to the original issue... multi-state order... i noticed another difference between the original creation, and the import

the original creation in the PE shows up like

test
1:one
2:two
3:three

but when it gets imported:

test
one
three
two

what I don't know is if this is just a symptom... or directly related to the cause, will see if I can't figure somin else out about that when i get home tonight

Posted: Wed Oct 21, 2009 4:02 am

Ok, spent a little time with sqlite administrator, and cmud, creating settings, checking what got put into the db changing ect, what i found was

1) Created settings had correctly *ish* set priority, primary state+ sub-states incremented by 1
2) flag column was only set for the primary on imported, but each on the created was set to the same as the primary
3) the state column was 0 for all of the imported columns, but on the created, the sub-states were equal to the priority column
4) the opt, and options columns are different, created, opt field is set for primary/sub-states, sub-states have options xml in them, but the imported has nothing in the options column and only the primary state has a value in the opt column

I realize that all this info goes throu a dozen different steps between import and saving to the db, but maybe the couple inconsistencies I found there will help find that 1 bit that isn't importing right.

Posted: Wed Oct 21, 2009 10:33 pm

Yeah, the bug about the incorrect order of the substates is already on the bug list. Mentioned this above, but it was a bit buried.

It's basically the State column that is causing the problem. That column is related to the priority, but is a bit kludged. Not sure if this bug fix will make it into 3.11, but I'll keep you updated.