Zugg Software :: View topic - [3XXB] Strange #MXP and/or #LOOP behavior

Posted: Fri Sep 03, 2010 4:45 am

I believe I posted this way back in 2.34 or so, but I had no concrete proof.
Insert the following in an untitled session:

Posted: Fri Sep 03, 2010 5:08 pm

Wow, that's really strange. I was definitely able to reproduce it...thanks for the clear instructions and scripts. I'll add this to the bug list and look into it. I have no idea what's causing it.

Beginner Joined: 03 Nov 2002 Posts: 27 Location: USA

I'll edit this to add more info when I have more, but I use MXP color codes (e.g., #SAY <color red>You're getting slaughtered!</color>) in some other #SAY statements. After running this alias (combining it all into one), I noticed three things:

1) The "failure" numbers are different depending on the number of #MXP statements you have in the #LOOP.
2) At some point during the loop, the displayed number flashes the color yellow and then goes back to what is designed in.
3) If you re-run the alias, each entire "LINE#: nnn" line is the color of the "nnn" (so, instead of a yellow LINE: and cyan 1000, you end up with a cyan "LINE: 1000").

Later, I noticed that after running this alias, my #SAY statements with MXP color codes were broken (from within triggers). I used a manual #SAY statement with those same color codes, and it worked... and "reset" my color codes, so now the trigger-based MXP colors are working as well.

EDIT: Existing MXP color codes continued to work (e.g., in a statusbar/window), just nothing coming as a statement from within a trigger/alias until after I manually typed one in.

Posted: Wed Sep 08, 2010 1:20 am

Yes, I am aware of this behavior. That was the reason I had the test set up the way I did (the odd loop behavior was collateral). I am also trying to find the root of the behavior you describe with no success. I find that for no apparent reason #MXP statements executed with aliases that are invoked whtin a #TRIGGER scope have no effect on the window. However, if you run the same aliases from the command line or invoke them from another alias which is not invoked from within a #TRIGGER scope, the windows will display the data. What is more frustrating is that on occasion things will work, then after I quit the session and come back, they have stopped working again. Another odd behavior is that the color of one entry will migrate to other parts of the window. I thought this was related to the number of writes being done which is why I instituted such a large loop, but as you can see if you run the test, the colors are displayed correctly. If I enable the "notrig" option (disable trigger on trigger), the mis-coloring seems to go away. Also, there is no failure from running in a #TRIGGER scope if done from a untitled session (as the above test shows), only in a live session this problem arises. What's more, this affects all scripts that write using #MXP, though this behavior only appeared when I started using #MXP from within GMCP triggers. That there is a relationship, this is apparent, that the relationship is linear, it is not. I am still looking, but frankly, at the moment I have run out of options.
EDIT Running the scripts in 3.23a, with the package which was current at the time, works. Running 3.23a with the package in the 3.24 or 3.25 state, fails. The failure is also applicable to 3.24

Wizard Joined: 17 Jun 2006 Posts: 1201

Want to see something else weird? Use your exact same test above just like you have it except after entering #show go and letting it run to completion enter test2 on the command line. Then keep entering test2 and watch what happens.

Posted: Wed Sep 08, 2010 7:27 am

Yes, it is weird. What's really interesting is that whatever is going on affects how the data is being displayed. I got it to the point where it was writing the stuff in italic font with reversed background, and all the colors washed out. However, once it cycles through and starts back so the first entry is in the 60 - 65 range, the colors come back. Note that white is the MXP default color.

Wizard Joined: 17 Jun 2006 Posts: 1201

Each #mxp line causes 8 numbers to be displayed too. It loops through and then displays 7 and so on. With the 4 mxp statements it displays 32 (8 x 4) numbers and counts down as you continue entering test2. Then displays 31 lines and so on. It's like it is looping through all the coloring codes and mxp tags. It does underline and italics and strikethrough and so on. It displays a new number on the main window every 64th iteration. Then once you complete the cycle it starts over again.

Posted: Fri Sep 10, 2010 4:17 pm

I actually did find the cause of this bug. The issue was with the DEST command (and any other MXP command that "gags" it's text). CMUD was not releasing a line attribute record when using DEST, so each time DEST was used and text was displayed on the same line, a new attribute record (which contains color info, etc) was being added to the line. Eventually this reaches the limit of the number of attribute records on a single line and was wrapping around causing corruption of the color data and screwing up the parsing of the line, causing the line to be displayed in the main window.

Fixed for 3.26

Posted: Mon Sep 13, 2010 3:35 am

The problem with the bleeding colors has not gone away. If you have two fields next to each other ( a label field and a dynamically-updated field) such as:

Posted: Mon Sep 13, 2010 6:08 pm

You'll need to give me the exact script you are using like you did in the first example of this thread. Using the script at the top of this thread I am not seeing any problems in 3.26 anymore.

Posted: Tue Sep 14, 2010 2:36 am

Here is the initalization code:

Posted: Tue Sep 14, 2010 4:25 pm

You didn't give me any test procedure for reproducing the issue. I don't know what to do with the scripts that you posted. I tried running mbtminit and mbtmdisp and they both seemed fine here, but you didn't say what I'm supposed to do or look for to see the problem.