|
Zugg |
Posted: Fri Sep 01, 2006 11:14 pm
CMUD 1.06 Status Blog |
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Sep 14, 2006 2:31 am |
If the windows are docked, then they end up tabbed. A docked window always has a parent, and when two windows are docked to the same parent, you get the tabbed windows.
If the windows are floating, then yes, they would both be floating at the same location and would be on top of each other. But I think that is what you'd expect. |
|
|
|
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Thu Sep 14, 2006 8:36 am |
Yes, sounds good.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Sep 14, 2006 11:38 pm |
Still fixing bugs today. I've gotten the session drop-down list working and added a New Session command to the main File menu, along with the Save Session As. The Session dropdown has items for each session icon that is defined, and also items for each hostname/port combination in the Hosts cache. If you select a session, then the entire session is loaded (including layout). Loading multiple sessions seems to work fine. If you just select one of the host/port entries, then it just creates a new window connected to that host/port without loading any layouts or packages. The #SESSION command also works now, and has the same effect of loading something from the sessions pulldown menu, except that if you use a new host/port with #SESSION, it gets added to the cache.
I've played with lots of different window combinations and have fixed a lot of bugs regarding the docking windows and the session stuff. The #WINDOW command now works properly again. And with the new Save Session As menu command you can press ESC from the main character selection window, then use #session or the session pulldown menu to connect to hosts, use the #window command to create various windows, and then dock the windows the way you want them. Then you use Save Session As to save the entire layout to a new session icon.
Or, you can load an existing session as normal, then use the Save Session As to make a copy of a session. Or, load an existing session, then connect to other hosts, add more windows, etc, then use Save Session As to save the new layout to a new session icon.
It all seems to work well, and removes a lot of the confusion from zMUD which had separate "layout" session icon types. It works well for quickly connecting to a different host or session.
Also, each session listed in the pulldown menu is available as a customized menu item. So, you can customize your toolbar, drag an item used to connect to a particular session/host to your toolbar. Then just click the toolbar button to connect to that session/host.
I've also got it so that customized toolbars are saved with sessions. The only downside of this is that with the toolbar loading, it overwrites *all* toolbars with whatever you have saved. So, for example, if I add a new menu item or toolbar item (in the default CMUD.TBZ toolbar file), then when it loads your own customized toolbars, anything that I added will be overwritten with whatever you had saved before. The only way around this is to delete the session specific *.TBZ file, or use the Load Toolbar command to load the default CMUD.TBZ file. It's an unfortunate side effect of how Developer Express saves and loads the toolbar system.
Still left to do: Expression Triggers, testing/fixing issues with Shared Package Library, and fixing the Autolog triggers. Looks pretty good for tomorrow. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Fri Sep 15, 2006 9:54 pm |
Ick...I hate it when this happens.
I was fixing a bunch of problems in the View/Directions and View/Tabs screen. This screen is like a "mini settings editor". It is set up to use the same edit panels on the right for each setting type, but instead of displaying the full tree view on the left, it just displays a list of the settings in the current module. I was adding a dropdown box to the top to allow you to select which module you are modifying when I ran into problems.
I was getting an error when adding a new record to the database. Now, this is a "filtered" view of the database...it only shows settings of a particular type and records with the correct Module index. Somehow the record wasn't being added to the index properly and after the Post I'd get a crash because it couldn't find the record that was just added.
After several hours of searching for the problem, I came across a line that I had added myself to the kbmMemTable 3rd party component. In the Append method, I was updating the record number of the record just added. This was overwriting the correct record number that was set when the table had a filtered index. So it was working fine without filters, but giving an error when using a filtered index view.
I went searching my old blog entries for where I added this line and in the http://forums.zuggsoft.com/phpbb/viewtopic.php?t=23528&postdays=0&postorder=asc&start=105 post I came across this:
Quote: |
In the process of testing these options, I ran into some wierd bugs that took a few hours to fix. It turns out that the kbmMemTable memory database component wasn't properly maintaining the current record when added a new record to the database. After "posting" a new record, it calls an AfterPost event, and in this event I link the new database record with the proper record in the linked-list of settings. However, in some cases, the current record wasn't being set after the Post, so in my AfterPost event, it was modifying the fields of some other record in the database! Not good...it caused all sorts of wierd crashes because the linked list and the internal database were no longer "in synch".
This turned out to be a bug in the kbmMemTable component. I added a line to set the correct record number after an Append operation, and that fixed the problem. |
But here's the problem. I've taken out that line to fix the filtered index issue, and I can't get it to crash now. So, I'm not sure what kinds of wierd crashes I was getting before that caused me to add this line. I've played in the settings editor and it all seems fine. I wish I had been more specific about exactly which test case was causing the problem. It's possible that some other fixes in CMUD were responsible for this error in the first place.
What worries me is how serious of a problem this blog post seems to indicate. If the linked list and internal database get out of synch, then there will be *lots* of wierd problems.
I'm going ahead and removing this line and will do more testing to make sure it doesn't cause the problem in the original blog to reappear. I'm delaying the release until at least Saturday to make sure this doesn't cause new problems. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Fri Sep 15, 2006 10:56 pm |
Well, a followup to this (and in case I ever need to refer to this later myself).
Seems that the *proper* way to reposition the database to the correct record after an insert is to set the AutoReposition property in the kbmMemTable. After I removed my line to reset the record number, I *did* find problems with the correct record not being set correctly after an Append. But setting the AutoReposition property to True seems to fix this. In fact, the help file for kbmMemTable even says:
Quote: |
If you make a change in a record, and that results in the record being moved to another place in the current index, it could result in the record seemingly disappearing from f.ex a DBGrid.
If you want the grid or any other controls to 'follow' to the new place of the record, set AutoReposition to true. |
In the case of the "mini settings editor" I *am* using a Grid control. And in the case of the main settings editor, I'm using a Tree control, which has the same issue. So it seems that this might have just been a case of not being familiar with all of the properties of the kbmMemTable component.
Hopefully I've got it working now. |
|
|
|
Tech GURU
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
Posted: Sat Sep 16, 2006 3:46 am |
Congrats on finding the bug Zugg.. it sounded like it would have been a nasty one to track down, especially since you couldn't remember why you flagged it the first time.
Looking forward to tomorrow. |
|
_________________ Asati di tempari! |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Sat Sep 16, 2006 5:48 am |
While I was implementing the Expression Trigger stuff, I discovered a problem with the reference updating. This is the code that updates stuff like status lines, buttons, etc when a variable changes. Seems that it doesn't work if sometime is compiled *before* the variable exists. For example, if you do this:
Code: |
#ST {Hp: @Hp}
Hp = 123 |
then the status bar does not update. This was reported by a couple of people in the Feedback messages, and I think it's something I want to fix in this version. I need to think about how I'll do this. The problem is that when the initial setting is compiled, the variable doesn't exist, so no reference can be added. The compiled code contains the name of the variable, so the next time the code executes, it gets the correct value. This normally isn't a problem in an alias or trigger, since executing the alias or trigger will still find the variable that didn't exist at compile time.
But with buttons and status bars, there is no way to know that a status bar needs to be updated when the variable is finally created. I'll somehow need to maintain a list of "weak variable references" that are unresolved references at compile time, and then check this list when a new variable is added, or something like that.
So tomorrow I have: variable reference issue I just described, fixing autolog triggers (should be quick and easy), and then testing the package library to make sure it still works (this is an unknown...I don't think it works with the new modules/windows properly). I'll be testing the last bit by adding the EnglishDirections and EnglishKeypad packages to the library. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Sat Sep 16, 2006 10:48 pm |
OK, I hate to disappoint everyone, but I'm not going to get 1.06 out today as I planned. It's going to be delayed until Monday.
I know that some people were looking forward to playing with it this weekend, but I've said before that I'm not going to rush this release. And during my testing today I've run into too many problems to allow me to release this with high confidence yet. I've made too many changes to the code today and I don't want to release it without more testing.
Work today is going pretty well, but I keep uncovering more serious bugs.
First, I implemented the "weak variable reference" stuff that I mentioned in the previous blog entry. This allows CMUD to keep a list of variables that have been referenced but not defined. Then, when the variable is defined, those scripts which reference the variable are recompiled with the correct variable reference.
This actually works pretty good. Now the status bar example from the previous blog entry works as expected. While I was at it, I implemented a reference list for system variables. This allows CMUD to respond to system variable changes, such as %mud.hp. I even set it up so that references to %secs are updated each second. For example, if you do:
then the status bar item will automatically update itself every second. This didn't happen before. It only works with system *variables*. Not with functions.
While I was working on this, I looked into the bug with putting %mud.hp in the status bar. With this new auto-update code, it should have worked. But it didn't. Turns out there was a major parser error handling @var.prop syntax with the #ST command. Even doing this:
Code: |
#ADDKEY var name zugg
#ST {Name: @var.name} |
wasn't working! In fact, I uncovered several more bugs still dealing with the @var.prop syntax. This is the main reason I don't want to rush the release today. I get nervous whenever I make changes to the parser like this. And while my testing script still seems to work, I need to do more testing with it.
Fixing the Autologin was pretty simple. It was just a matter of removing the "AutoLog" class from the Default Settings package. The autolog triggers in CMUD are placed into the AutoLog class. So when this class existed in the default settings, the autolog triggers were being placed in that package, which isn't saved with the character. By removing the Autolog class from the default packages, CMUD now properly creates the Autolog class within the current window, and puts the triggers within that class as expected. So that was easy.
Creating the EnglishDirections and EnglishKeypad packages was also really easy. With the way 1.06 works now, I simply went into the settings editor, did a "Show Default packages", did "New Package" and entered "English Directions", which created a new package tab. I then dragged/dropped the two class folders containing the directions from the Default Settings tab into the English Directions tab. Then, in the English Directions package tab I just checked the Published checkbox to make these directions available to other packages. It was actually easier to do than it is to explain it :) But this was a good test of the new package system...it worked just the way I wanted it to. I followed the same procedure to create the English Keypad package. Right now this package contains both the normal and diagonal directions. But it will be pretty trivial for anyone to change this who wants to.
I haven't had a chance to upload these packages to the shared package library yet. That's next on the list to work on. I don't think the shared library works properly right now and it needs some fixes to handle the new module/window stuff. I might need to clear out all of the existing test packages that people have already uploaded, but I'll let you know if I need to do that.
The package library fix is the last thing on my to-do list for this version. But as I said, with all of the changes today I want time to go through and test it a bit more. I also want a chance to look through my automatted crash dumps a bit more and see if I've fixed most of the reported crashes from 1.05.
I'll still be working more tonight. But tomorrow is our normal day off, which is why I won't be able to release it until Monday. Sorry for those who are disappointed in the delay, but I think it will be worth it. I'd really like the 1.06 release to be useable for a change. |
|
|
|
Tech GURU
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
Posted: Sun Sep 17, 2006 7:57 am |
Hey Zugg... no worries about having to push it back. I was looking forward to it but being a perfectionist too I know you want to put out the best product possible.
Looking forward to Monday. |
|
_________________ Asati di tempari! |
|
|
|
hav Wanderer
Joined: 05 Oct 2004 Posts: 61 Location: Riga, Latvia
|
Posted: Sun Sep 17, 2006 8:18 am |
Certainly take your time. I wont mind a few days if it means less bugs, definately looking forward to a stable release. And on that note, any chance for another trial reset? Been awhile since last one.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Sep 19, 2006 6:08 am |
Well, for better of worse, 1.06 is out now. I got it uploaded at 11:45pm (my time, not the server time). So I barely made it. It was a very annoying day. Each time I thought I was ready for the release I found new bugs. With all of the bug fixes that I did today, it's possible that I screwed something up at the last minute. But I tried to test it before I uploaded it to make sure it mostly worked. If there are major showstopping problems, then I can always do another update later this week.
I seem to be pretty consistent at getting a new version each month (almost exactly to the day). Assuming there are no show-stopping issues, the new version will start adding new features and dealing with stuff in the "Not implemented yet" document. I'll be updating that document later this week with more details on expected schedules for various new features. I'll also be writing some of that promised documentation for the new package/module/window stuff. Although I think it's all working a bit more intuitively now in 1.06.
I'm hoping to get new versions out more often than once a month. At least that's my goal. I have a particular date in mind for the public release that I'd really like to make if at all possible. More on that later.
In any case, this brings the 1.06 blog to a close for me. I'll start a new blog entry for 1.07 when I get going with that. Or, if it has some major new features, I might jump ahead to v1.10.
Hav: No, the trial is not reset in 1.06. Remember that resetting the trial is a very rare occurence. You should never count on it. It's possible that I'll reset the trial for the public version, but I haven't decided yet. |
|
|
|
Tech GURU
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
Posted: Tue Sep 19, 2006 6:14 am |
Thanks for the release Zugg.. I checked and didn't see it and got worried. I've got to remember you're on mountain time.
|
|
_________________ Asati di tempari! |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Sep 19, 2006 6:26 am |
Heh...I almost gave up and delayed it another day. I was really getting frustrated with it. But I have some errands to run tomorrow, so I really wanted to get it out today. So yeah, it's a late night for me
|
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|