Zugg Software :: View topic

Posted: Wed May 24, 2006 6:34 pm

Zugg that is real bad. The sooner you get CMUD out the better. Oh and don't you dare tell me that when you do you're sticking around to debug. Get yourself on holiday for at least a week, preferably two and when I say holiday I mean away from the house with no computer or business books just some light reading.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Thu May 25, 2006 4:58 am

Taz: I'm hoping to watch the forums for the first couple of days and answer questions and then take about 2 weeks off and not touch the computer for at least a week of that. And then later this summer after another release I'll take some more time.

The fact that I'm exhausted is really starting to show though. Today I spent all day on the Preference saving and restoring from database files. It seems to be full of bugs. I'm getting wierd Variant conversion errors, and I'm getting various SQL errors. It works most of the time, and then just goes crazy sometimes. It makes me thing that there is a pointer problem somewhere, but I'm having trouble finding it. I'm just making some stupid coding mistakes.

I'm going to quit for the night and tackle it again tomorrow and hopefully get it working. I'm crossing my fingers for a decent night of sleep.

Posted: Thu May 25, 2006 10:21 am

Phew, glad to hear that you'll be resting.

Yes, when you get in this sort of situation it is very hard to concentrate fully. It is horrible too because it's a nasty circle where because you can't concentrate properly to sort things out the more you worry and hence the more you can't concentrate.

I hope you get a good nights sleep too. *fingers crossed also*

Posted: Thu May 25, 2006 6:25 pm

Yay! I finally got some sleep last night! I tried a somewhat different strategy that seems to work (at least for one night). After reading before bed, when I started thinking of programming stuff, I got up and went to the computer and did another 45 minutes of programming. It got the stuff out of my head and then I was able to sleep. Of course, since I went to bed at 3am I slept until 11am, but at least I slept. If I have to shift my hours a bit to make it work, I'll do whatever I need to do at this point.

Of course, this method won't work if I'm too deep into a problem that requires too much brain power. But what I did late last night was add the advanced features to the Preferences editor to allow you to control exactly which package preferences you are modifying.

I added a small pull-down menu to the upper-right corner of the window, where it's not distracting to normal users. From this menu you can turn on "Show changed options as Bold" and now any preference that has been changed from the default is shown in bold text. You can also set the mode to "absolute" or "relative". In relative mode, the option is shown as bold if it's different from it's inherited package. In absolute mode, the option is shown as bold if any package in the loading chain has changed the option from the default.

From this menu you can also select which package or window you are viewing preferences for. You can also select from the inherited chain, or from the list of other preferences that "depend" upon the current package you are viewing.

Not only will these features help package developers tweak their settings, but it should be a great debugging tool for me to look for those pointer problems today. And I've got to admit, that from a "coolness" point of view, the preferences editor is just really cool. It looks great and works exactly like normal users would expect, but then has these advanced features behind-the-scenes for people who know what to do with them. I'm really proud of how it turned out.

OK, so today I'll be trying to track down the pointer problem that is corrupting the preferences sometimes. Hopefully with the new features in the preference screen it won't be too hard.

After that is done, then I get to work on the CMUD text editor screen. This is the last screen that uses the old syntax-checking component for the editor window. It's getting converted to the zApp Memo control that the rest of CMUD uses for syntax highlighting now. The editor is also one of the older parts of the ported zMUD code and needs to get replaced. As many people have discovered, it's not really a true "editor" and has a wierd limit on lines and wierd cursor control sometimes.

Basically, the old zMUD editor is being replaced by something more like the zApp Editor Demo. It's compiled rather than interpreted like in zApp, so it should be fast. It will handle multiple files in multiple tabs, but instead of using the zApp Tab control, it will use the new docking system so that each file is in it's own dockable window. So you can drag the tabs and re-dock the windows to view two files side-by-side, for example. It will have the default syntax highlighting for zScript, but as with the zApp memo control you'll be able to load your own syntax definition files as well.

This might sound hard, but most of this code was written for zApp already, so it's just a matter of integrating more of it into CMUD. It should only take about a day of work according to my plan, so it's worth doing.

The main reason for doing this is that this new editor is the key to the new logging system that supports RTF and HTML output. That will be the next step once the editor is done. It's not absolutely required for the first beta, but it's something that I really wanted to get done. Hopefully it will be fun and will help re-energize me for the release (which is probably still two weeks away Wink

)

Site Admin Joined: 29 Sep 2000 Posts: 389 Location: USA

Lest anyone think that the good night sleep is soley attributable to a minor change in habits, I'd like to report that I'm also drugging him liberally with various nutritional assists, aka vitamins and amino acids. I personally think that makes at least as much difference.

Oh yeah. Two solid weeks after the release. At least.

Posted: Thu May 25, 2006 6:51 pm

Yep someone just asked about the logging today on the wishlist post and I said it would be in RTF. They then went on to request some threads that say what has been asked for that has been done and one for what has been asked for but won't make it into the beta. I'll get on to that tomorrow, just about to go out now so don't have time today. Probably going to be a fair trawl so I'd like to spend a good couple of hours focused on it. Once I'm done I'll close that thread and possibly the YAWL thread if I subsume that one too.
<edit>
Oh yeah I forgot to add that I'm really glad you got some quality sleep last night. *cheer*
</edit>

Posted: Thu May 25, 2006 7:18 pm

I'll be starting a new thread soon on "What is missing from the Beta" which will have a lot of details in it.

And actually, while you are moderating, go ahead and lock the "zMUDXP Poll" and "zMUDXP wishlist" threads and set them to be normal threads if you have the permission to do that. Otherwise I'll do it later.

Magician Joined: 29 Nov 2005 Posts: 482

lol the joys of forum moderation :P

Glad to hear things went well. Hopefully things will continue on their streak :)

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Off-topic: Saw Xmen-3 last night - thought it was great! I never got into the comics or anything, so I don't know how it'll sit with those who did, but both me and my girlfriend loved it. Not going to say anything more than that, don't want to drop spoilers before y'all get to see it :)

On-topic: When you were mentioning converting the editor with syntax highlighting, I was thinking, will the command line also do syntax highlighting? Does it use the same control? Just curious really, if it's just a matter of ticking a box or something might be worth considering. Thinking at least it might be nice if it could dynamically colour aliases and variables like the settings editor does... but it doesn't really matter either if it's not :)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Taking care of those old threads now. Gratz on a good nights sleep.

Edit: Grr, I can't seem to unsticky them. They are locked though with little posts so everything is clear. Sorry Zugg. Guess you still have to take care of that too.

Posted: Fri May 26, 2006 1:35 am

Yes, the command line uses the same control Smile

I haven't enabled syntax highlighting on the command line yet, but that's certainly something that will be pretty easy. Thanks for the X3 preview. When we go on vacation I'll have to get caught up on our movie going. We want to see MI3, X3 and Davinci Code sometime in the next month or so.

Vijilante, thanks for trying on the posts. I forgot that only the admin can unsticky stuff. So I went and took care of it.

Preferences are all working great now, so it's on to the editor coding!

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Off Topic: Scary enough, Over the Hedge ended up being a fairly good movie.

Posted: Sat May 27, 2006 6:33 am

Well, didn't get a whole lot done today. I slept ok last night but was still tired all day long and had a hard time thinking straight. I did some non-programming stuff such as the new CMUD articles over in the Knowledge base. I got the basic editor user interface done, but haven't coded some of the zMUD functionality for sending lines to the MUD yet, nor does it capture text from the MUD yet. I still have to learn more about how this 3rd party RichView component handles reading and writing file streams.

Took tonight off to watch last week's and this week's Lost episodes. What a mind trip. Hopefully with another good night's sleep I'll be fresh for a good day tomorrow. As I posted on the official ETA thread, I really do think I'm getting close. After the editor (which I admit I had forgotten about earlier), the rest of the stuff on my list is all "easy" and less than 2-hours each in duration. All of the "difficult" tasks are done.

It was actually a big help going through some of the forum posts and reviewing everything. I'm really happy that everything promised in the "What is CMUD" thread are absolutely part of the first beta release.

Posted: Sun May 28, 2006 3:50 am

What another annoying day. I thought I was done messing with 3rd party components, but boy was I wrong.

When working on the editor today, I spent most of the day fixing problems in the Open and Save file dialogs. These dialogs were written for zApp, and something happened to them over the past year. Looks like it was related to some DevExpress updates. Also, the theming was all messed up. Again, this should have all been working back with zApp. I hate working on stuff that was already supposed to be working.

Then I ran into issues with the new docking system. Remember that I'm using docked panels for each file in the editor to support multiple files. Well, the new docking system doesn't distinguish between "hiding" and "closing" a panel. All of the X close buttons in the docking system only *hide* a panel. They don't actually get rid of it in memory.

In the main zMUD code for the fly-out panels, I use the OnShow and OnHide events to allocate and deallocate the window frames shown in the docked form. But this won't work for MUD windows, nor will it work for the editor windows. The code that was supposed to create and destroy the MUD windows was being called, but since the docked panel was just hidden and not destroyed, then the MUD window still shows up in the Windows list and when you try to select it, it crashes because the MUD session object has already been freed.

In fact, the events in the docking system are pretty pathetic. In the editor, I need a "CanClose" event to allow the user to save changes to the file before a panel is closed. They don't have any support for this either.

So I ended up modifying their source code again to support the stuff that I need. I also sent them some "feedback" on making their components more useful. After all, a multi-file editor with tabs is a pretty common application these days and it's pretty sad that they don't support simple stuff like this out of the box.

So that all took most of the day. Then when I got into the actual read/write routines, I learned that I cannot stream MUD log files out in RTF format. HTML will be fine, but with RTF there is a header that needs to contain all fonts and colors that will be used in the file. At the time the log file is opened, there is no way to know what fonts and colors the MUD will use. So there is no way to stream an RTF file as text is received from the MUD.

I can support saving the editor file to RTF format. So you can load a log file into the editor, then save it as RTF if you want. My guess is that just having the HTML log file format will be good enough. There isn't anything in RTF that can't be done just as well in HTML. But it looks like I'll have to tackle that I/O stuff on Monday.

Posted: Tue May 30, 2006 4:23 am

Well, I made a bit more progress today, although part of it was still very frustrating.

I started by finishing the editor window. I added all of the stuff for capturing text to the editor and for sending text and commands from the editor to the MUD. While I was implementing the "Prefix" string feature, I went ahead and added a new "Suffix" string. When enabled, the prefix string is added to the start of each line sent to the MUD, and the new suffix string is added to the end.

While I was working on this, I ran into another problem with keyboard focus. It's a small detail, but it's important that when the editor window is first shown that the edit field has the keyboard focus. Otherwise you have to click on it, and when using Ctrl-Shift-Enter to open the editor, you don't want to have to click the window to focus it.

This ended up being a pain. Delphi just isn't set up to handle "forms" that are docked. For example, when the editor is floating, this is actually an EditorForm with a Parent of Panel with a Parent of FloatingForm. In other words, when docking, the form is contained within a panel, which is then contained within the docking control (floating form or docked panel). Now, when Delphi gives a floating form the keyboard focus, the *panel* gets the focus instead of the child EditorForm.

Fortunately, I'm not using Delphi's Panel object directly, but am using my own variation. So I was able to override the SetFocus routine for my Panel so that it searches the panel for the first control that can be focused. Or, if a form is docked within the panel, the active control of the form is given focus. This finally fixed the focus problems with docked forms.

But then I ran into another problem, and this one was *really* aggravating. I discovered that the keyboard shortcuts were all messed up and confused. Even when the Editor window was floating, pressing Ctrl-A would activate the Aliases function over in the main application form, instead of doing a SelectAll within the editor window.

Shortcuts are handled by the menu system. Yep, that's right, it was time to delve into the Developer Express ExpressBars menu system *again*! All of the items on a menu and toolbar are held in a BarManager component, which is a global component placed on a form. Well, DevExpress isn't set up to handle docked forms properly. In the example above, the BarManager is a component added to the EditorForm. But this form is now within a Panel, which is within the outer FloatingForm. So DevExpress is stupid and looks in the FloatingForm for a BarManager component, and doesn't find one. So it then looks on the main application form and uses the BarManager found there. So it ends up using the menu shortcuts of the main application.

Bah! This took forever to track down. Once I found it, I modified their code so that it searches from the currently focused control and traces it up through the hierarchy until it finds the first form that contains the control. Then it gets the BarManager from that form. So this starts with the editor Memo component, and keeps looking at it's Parent field until it gets to the EditorForm. Then it properly gets the BarManager from there. If no BarManager is found, then we continue looking for a parent form.

This ends up giving the correct result. When the EditorForm is floating, Ctrl-A performs a SelectAll. When the EditorForm is docked, Ctrl-A performs a SelectAll if the editor memo currently has the keyboard focus. And if you use a short-cut that isn't defined by the editor panel, then the main application form handles it.

I remember a *long* time ago I had to do something similar for the Toolbar2000 menu components. But back then I really kludged it. Instead of modifying the Toolbar2000 source code, I would trap the menu keys before Windows sent them to the menu system. I would play games with enabling and disabling various menus and toolbars so that the correct one would get the shortcut keys. I think my new solution is cleaner, but we'll see what side effects we end up with.

That all took most of the day. I just finished adding the first part of ANSI color support to the editor. The Memo component from zApp (which uses something called TRichView, a 3rd party rich-text editor) didn't have any support for ANSI colors. I've added the parsing and color support for text captured and sent to the editor window. I still have to add support to the File reading routines so that you can open a file that contains ANSI colors. I'll finish that tomorrow, and I don't expect it to take very long.

That should finish the editor. I'm annoyed that I'm still finding some really basic bugs such as the keyboard focus and shortcut menu system for docked windows. Seems like that kind of stuff should have been found and fixed long ago.

Oh well, at least the editor works well. Having multi-file support with multiple docked tabs is really nice. Now you can have your normal editor stuff in the main tab (the #Capture command always sends text to the main tab). When you open a file, the contents of the file are placed into a new tab. So this doesn't erase anything that you might have had in the editor already.

And, of course, since it's a normal text editor now, there isn't any line limit. You can load large files, edit them, and save them without worrying about losing the lines at the beginning of the file. It already supports saving and loading files in text, RTF and HTML formats. Once I get the ANSI color support added to the file loading routines tomorrow, then you will be able to load an ANSI color log file and then save it as HTML!

I've decided not to add the HTML logging support yet. It wasn't something I promised in the first beta in my original announcement, and I want to get this first beta released and stop adding new stuff to it. HTML logging will be added during the beta period. It shouldn't be hard, but everytime I say that it seems like something takes another week.

Posted: Wed May 31, 2006 6:17 am

Today was a pretty productive day. I got all of the file I/O stuff working for the editor. It can now read/write ANSI color files, just like the editor in zMUD. It's actually a bit more efficient when it comes to generating the file. zMUD added a lot of unneeded ANSI codes and was pretty brute force.

I also got the HTML read/write routines for the editor completed. So you can load an ANSI log file and then save it as ANSI, RTF, or HTML. You can then load the RTF or HTML back into another tab in the editor, and it looks identical to the original log file. With the rich-text editing tools, this even gives you a basic WYSIWYG HTML editor built into CMUD, which might come in handy sometime.

Adding the HTML writing to the actual log file streaming shouldn't be hard, but as I mentioned, I'm not going to do that before the first release. I'll add it later. For now it will have to be good enough to load ANSI files into the editor and then save them as HTML manually.

OK, now I'm down to a bunch of things that should all be quick and easy (bah, there I go again, saying stuff like that). Tomorrow is another "chore" day, so I won't be back to programming until Thursday. I still need to add the function to the settings editor to send a package to the shared package library. But the server scripts are all written and tested, and the package editor already generates the needed XML, so it's just a matter of putting together the HTML POST request. Then, I need to finish a loose end in the shared package library itself. Right now, when you download something from the shared package library, it gets stored in XML format. This needs to be changed so that it actually stores a complete *.PKG database file. Again, should be easy.

I think I've got about 3 days of loose ends to complete, then about 2 days working on the web site store to get CMUD ready to sell and to get the discount offers set up. So, I still really think I might be able to get this released next week. Keep crossing those fingers!!

Posted: Wed May 31, 2006 7:54 am

Not to sound pushy, but if you do make it out in a week any idea's of when pro will be ready? I'm really looking forward to Pro because of the mentioned SSH ability. Will it be able to handle keys too? I hate typing my passwords all the time :P

Posted: Wed May 31, 2006 5:07 pm

The SSH plugin (Pro version) is what I plan to work on first during the beta period. So, after a couple of weeks of vacation, and then a couple of weeks fixing any of the major "show-stopper" bugs in CMUD, I'll then start work on the SSH support. So yes, this is a very high priority for me too.

As far as keys, I can't promise anything yet. I need to learn more about how SSH works. But feel free to start an SSH topic over in the CMUD Beta forum where we can talk more about specific SSH features that you'd like.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Wow, a week? It's good to see that we're down from the infinite 'couple of weeks' :)

I still think you should do a closed beta (alpha?) which is only released to the zMUD guru's before you do the public one, go on vacation for 1 week, fix the discovered uber-"show stoppers", release to public beta, go on vacation for another week or two, then proceed to the next round.

The only reason I'm saying this is there is a lot of hype and as a result you will have a huge number of people signing up for beta, but they're not going to be as forgiving as the guru's. I mean the hype is that CMUD is the 'one client to rule them all and in the darkness bind them'... and as such, beta or not, people will be downloading it as if it were the full public version. I mean my expectations are from day one it's going to be more powerful, more pretty and less buggy than zMUD 7.21. I know I'm not being realistic about it, I keep telling myself that, but the bottom line is when I close my eyes and go 'mmm, CMUD' that's what I see and I think that'll be what most of the rampant sign-me-up beta testers will see.

---------

Off-topic: That micro-ISV book turned up yesterday, been finding it very interesting. I'm not sure I've found a pain worth fixing yet, but I have a few ideas (one in particular I'd like to bounce off you when it's a little more refined), and a lot of it can be applied to my current job anyway. Definately glad you recommended it anyway :)

Posted: Wed May 31, 2006 10:46 pm

Rainchild may have a point there. I think it is certainly worth considering. Anyway it's up to you and you'll probably just release the beta to everyone. Whatever you do please do take some well deserved quality time to yourself(ves), Chiara included.

Posted: Thu Jun 01, 2006 2:33 am

No, I'm just going to do a full beta release. I have found in the past that closed beta don't give me enough feedback. Also, we need to get CMUD available for people to start purchasing. That's still a major driving factor.

Some people are always going to download the beta as if it were a public version, whether it's the first beta or the tenth beta. Doing a closed beta won't change that.

The only downside of the open beta is that some people who are impatient and expecting a more stable public version might be annoyed by the bugs and spread bad word-of-mouth. But that's always a danger. And over time, I think the quality of CMUD and the process I use to continue to improve CMUD (like I did with zMUD) will speak for itself.

It *is* a tough decision. I've definitely thought about sending CMUD out to selected Gurus (and other people who have been active in this thread) early. And I still might do it. But it would only be a couple of days early. I can't really afford to take a vacation without having CMUD sales start to come in first. Even though a lot of people might wait on buying CMUD, since you can only use the Shared Package Library if you are registered, I expect that to still drive some sales.

Mainly I'm just going to need to have a thicker skin than normal and not let some negative response discourage me. I need to be prepared to deal with those people who are expecting something as stable as zMUD, and to be prepared for those people who are still upset about paying for CMUD. I tend to be rather sensitive sometimes and I let negative comments really depress me. This is just something that I need to work on and not let bother me.

But yes, it's very exciting to have gone from the inifinite "just another 2 weeks" down to the "just another week". Even if it's more than a week, it's good progress. I just have to try not to kill myself trying to push this release out.

Finally, I'd be happy to talk about the micro-ISV book and any related issues. In fact, after I have had some time off from programming, I am planning to do a few articles on micro-ISVs myself. After all, I have *some* experience with this after being in business for ten years. A lot of these books give good advice on *starting* an ISV, but I think I have some perspective on keeping an ISV running, especially when income starts going down instead of going up. I've certainly made several big mistakes along the way that I can share with people.

Posted: Thu Jun 01, 2006 3:48 am

If you do decide to send out some copies early, please include me(CC has been waiting for it, heh)! While I don't mud, I am developing my own so I'll be using it all day anyway.

If you decide to do some testing of the SSH plugin before releasing it, that's something I'd definately be using constantly all day long!

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Horray Zugg for getting so far.

I do tend to agree mostly with you that a closed beta would probably not get you that many early bugs. More likely than not you will catch any really critical bug in your tests leaving mostly intermediate and minor bugs for us. However, I do recommend that you stress, even more than in previous times, the point that as with any beta version of software it will contain bugs, and that the beta version is in no way recommended for day-to-day use of a regular user that is not willing to put up with the bugs. This should be made clear very near the download link in a way that jumps out at people downloading it.

Posted: Thu Jun 01, 2006 7:42 pm

I remember Zugg making downloaders read a notice similar to what you just stated during the last beta. I had a good chuckle about that. I doubt there is a sure way of preventing morons from downloading beta software. The Universe is always striving in creating better morons. Twisted Evil

It's a never ending battle between programmers and the Universe.