Zugg Software :: View topic - [303B1a] Settings Editor cannot process settings

Posted: Sat Jan 31, 2009 9:15 pm

This problem began last session as follows:
I have 2 packages loaded: A) Aardwolf and B) AardwolfServices (which is the package where all the new mapper development is done).
The first thing that happened is that all the settings disappeared from the tree view for package A. This didn't bothered me much, since it happens at least once a session and all I have to do is close the Settings Editor, wait a while for whatever caused the problem to go away, reopen the Editor and the tree view will be back. The view for package B was normal.
Instead of the view for Package A returning (as usual), the view for package B also disappeared. (NOTE: this does not affect the function of any of the settings. I can still invoke the aliases, the triggers will fire, etc,. I just can access them via the Editor).
With both views gone I decided I had a enough and terminated CMUD normally.
When I next started CMUD, what I found was a flat view of the settings. That is not a tree structure of Window/Module/Class as one would expect, but just a listing of mixed settings (aliases, functions, variable and triggers) in no particular order for both Package A and B. The tab I chose to view doesn't matter, one gets the same settings displayed on either tab. To find a class I must search a setting within that class, clear the FIND field so that the settings view returns to "normal" and then click on the "Go up to the previous folder" button until the class for that particular settings appear. I can then select the class setting, change it to XML and copy it out in the hopes of reconstructing the packages. This technique is not guaranteed, though. Some classes are not accessible no matter what I do. In particular, the main window setting is never unavailabe.
Here is the biggest problem. Even if I start out in a blank session and attempt to create a new package (so that I can rebuild) the problem persists. Creating a new package works, the problem is that no settings can be created for that package because CMUD still thinks it is in the untitled tab (package).
I have un-installed and re-installed the CMUD and the problem persists. I can load a package that I had for CMUD 2.14, and the problem persists.
So to recap: There is no tree view of the settings. The settings displayed are a mix of settings from all modules and classes for all packages. The package tab chosen makes no difference. It doesn't matter whether one is in a named session or a blank session. The only thing that resembles normalcy is that if one clicks on the drop-down manu (Select a class folder) the correct tree-view will appear though clicking on any of the classes has no effect.
It is clear to me that the packages are not corrupted in the normal sense since one is able to use the them. However something is wrong with the package, otherwise because I tried loading the packages under 2.37 and the problem appeared then. One thing that I believe must be the case is that once a version of CMUD opens this package, CMUD itself becomes corrupted. In the instance where I tried opening the one of the packages with 2.37. I had to uninstall and re-install 2.37 to get it to work properly again. This does not fix the problem with the Beta version, even in a brand new reinstall, I cannot create a new package in a blank session.

EDIT: The flat view shown in the Settings Editor is in the standard collation (alias,variable,trigger,function) and in alphabetical order regardless of original class residence. Not all the settings in the package are shown, though. No window, module or class appear in the display. Additionally, the statement I made that the scripts ran normally is not quite true. The shown settings run normally. In order to allow a script to run, I must first "activate" it by searching for it and thus forcing it to appear in the view. Once this happens then the setting becomes usable.

EDIT: I tried the following:
I re-installed CMUD 2.37 in a pristine folder so that there weren't any settings. I was able to coax the CMUD 3.03a to allow me to view the main window setting, from that setting I extracted the settings for package A via XML. I went to the 2.37 Editor Setting and in a blank session (there are no sessions to begin with) I created a package using the XML from the beta version. The package was fine, I was able to view all the settings and execute all the scripts.
I then un-installed CMUD 2.37, re-installed CMUD 3.03a BETA. In a blank session I accessed the package that I created above. The package was grabbled exactly the same as the actual package I would get if I started my session. So it isn't the package, it's something else. The package is viable. One thing, though, I made no changes to the package when I loaded it into the Beta version, however, the size of the package changed by 3K (I saved a copy of it before loading it just in case and there was a size discrepancy).

EDIT: I also tried the following:
I re-installed CMUD 3.03a in a pristine folder same as the 2.37 version. Loaded the package from the 2.37 version (a copy of the original good one) and in a blank session I loaded it. The package is fine. I then deleted this package from 2.37 and loaded the package that I normally use from 3.03. It loaded fine. This indicates that the problem is with some setting in CMUD that is causing this problem. The setting must be somewhere in the version folder since a pristine version doesn't have this problem.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Wow that is a wall of text.

From what I can gather:
1. You have had frequent problems with the tree view in the PE since switching to 3.03a.
2. Item 1 usually corrects itself.
3. Instead of fixing in this instance it saved something in a damaged state.

Do you still have both the damaged CMud and the good one installed?

Can you get a diff utility to try to make comparisons between those 2 directories? Even if it doesn't find the exact problem it may narrow it down. Right now it sounds like it may be something in the docking system that is resulting in the bad display, but what is causing that to get messed up could be elsewhere in the new mapper code.

Where you using the mapper in your session where you first noticed this problem?

Can you find any way to make this problem occur again from a clean installation?

Posted: Wed Feb 04, 2009 1:32 am

As it turns out, the package is not damaged. If I un-install CMUD, and then re-install with a new data folder, I can move the package to this data folder and it will load properly. This means the problem is external to the package. The damaged view does not reflect the contents of the package, though it affects access to it. As I pointed out above, one cannot execute any scripts that are not in the damaged view. One can force access to said script, by using the search function in the Settings Editor. Once the script (variable, trigger, etc) is found, and becomes displayed, it can be accessed. One can also move up the tree (somewhat) by using the "Go up to the previous folder" button. I failed to go all the way up to the session window's folder this way, though. Even so, being able to move up the tree does not change the flat, damaged, view, it just adds the contents of whatever folder I find to the mix. The display is alphabetical by the normal contents order (alias, variable, trigger, function).