Zugg Software :: View topic

Posted: Thu Jan 24, 2008 7:18 pm

Rorso, CodeGear already offers free versions of Delphi, called their "Turbo Delphi" versions. I've looked at the Lazarus FreePascal project, and honestly, Delphi is still lightyears ahead of it. Fortunately, building your own component packages represents a small percentage of Delphi users, so most users are never going to run into these issues. The Caching problems only occur when you are using a large number of interdependent packages and then make a change to one. If you are careful and don't change the "interface" of a package, then there is no problem. My problem is that some of my older components were not really designed properly to be as modular as I'd like. With properly designed packages with minimized dependencies, I'm sure there would be less problems. But it's still frustrating sometimes.

As far as using Free alternatives, that only works in certain cases in my experience. It's very hard to find free alternatives that are actually supported. I've had to dump many excellent free 3rd party components because they don't support newer versions of Delphi. Yeah, I've got the source code and I can spend weeks trying to get them working in Delphi 2007, but I don't have that kind of time and working on other people's code is one of the things I hate the most. I'd much rather use paid components from a reputable vendor like Developer Express and report bugs and install their updates and be assured that I'll get good support for problems, and good support for future versions of Delphi. The number of Free components or tools that I use that I would recommend to anyone is a pretty small list (GExperts, Subversion, TortoiseSVN, Scintilla, kbmMemTable, ZeosLib)

Today I started getting bugged by the "Green Ribbon of Death", which is what the new book Window Vista Annoyances calls that green progress bar in the Address bar of the Vista File Explorer. The link I just gave is for a limited preview of this excellent book (I've already ordered a printed copy from Amazon).

According to this book, the green progress bar shows when Explorer is just taking a long time to respond to a task, and can be displayed if File Explorer "crashes" internally and then need to recover. He mentions that when Thumbnail previews are enabled (the default), a bad file or bad codec can cause File Explorer to crash and show the progress bar. The method that I used to try and turn off thumbnails is different than what he mentions in the book, so I've tried his method and rebooted to see if that helps. If that doesn't help, then I'm going to start looking into a Vista version of the Directory Opus explorer replacement that I was using on my XP system. Because this green progress bar just drives me crazy and brings my working speed to a grinding halt.

Posted: Thu Jan 24, 2008 11:30 pm

Well, I gave up and decided to upgrade and install the Directory Opus program from GPSoft. I had used this excellent Explorer replacement in Windows XP for many years. I thought I'd try to live with the Vista Explorer, but the "Green Ribbon of Death" was driving me crazy, and I started to miss a lot of the features that I was used to having in DOpus (like being able to get a "flat" view of all files in a folder no matter what subfolder they are in...great for deleting all SVN files when moving stuff around).

Anyway, I found that last year they upgraded DOpus to v9 and added full Vista support. Having installed this version on Vista, I can say that I'm *very* happy with it. I haven't run into any problems at all, and there are more features here than I could possibly learn any time soon. If you love software with *lots* of features and the ability to customize *anything* (kind of like zMUD/CMUD), then this software is for you. If you are intimidated by large numbers of options and preferences, then you'd probably be better sticking with normal Windows Explorer.

One Vista feature that I *really* like is that they have streamlined the UAC prompts. There were many cases in the regular Vista Explorer where you might get prompted two or three times for a single operation. DOpus optimizes the UAC prompts so that you only get prompted once for an operation (see Here for more details on this). They even have an "Admin" mode that you can enable that will allow you to perform multiple file operations without any UAC prompt (except for the single prompt when you enter "Admin mode"). When you enable "Admin mode" you can set a timeout so that it reverts to normal mode after the timeout. This is *great* when you are copying multiple files to/from the protected Program Files or Windows directories.

You can completely replace the Vista Explorer with DOpus so that all normal operations that open a file listing will open it as a tab in DOpus instead. Unfortunately, the File Open/Save dialogs in Vista still use the normal Vista Explorer. So when I use the File/SaveAs menu in programs like Microsoft Word, I still get the annoying Vista Explorer and still get the "Green Ribbon of Death" when I try to expand directories sometimes. Still really aggravating when all I'm trying to do is save a simple document to a directory. Sorry Microsoft, but we really *don't* need the full File Explorer in the simple Open/Save dialogs. Maybe the Vista Annoyances book will show me ways to simplify those dialogs so they are faster.

Anyway, if you are annoyed with the File Explorer in either XP or Vista, I can highly recommend DOpus. I haven't done a systematic search of other similar products, but I have no reason to since DOpus does everything that I can imagine, and does it quickly and efficiently (even if there is a learning curve).

Back on the subject of Delphi components...I successfully upgraded and installed the TMS Software component pack for Delphi 2007. I debated over whether I'd install these or not. They overlap the Developer Express components in many areas, and their source code isn't nearly as good as DevExpress in most cases I have looked at. And they install a *lot* of components, which can slow down Delphi sometimes. I really only use a handful of components, like their HTMLLabel component. But the upgrade price was pretty low, and they are one of the few companies that really maintain their products and update them quickly for new versions of Delphi and new versions of Windows. They were one of the first to have Vista components, and are still the only ones that support the Vista toolbar "ribbons". Not that I plan to use that...I hate ribbons. But it was a low price for a *lot* of components, so I went ahead.

I also finally got a Source Difference tool that does a "diff" based on Delphi syntax differences. It's from the same company as the excellent ModelMaker Code Explorer plugin for Delphi (which I couldn't live without). This made it easier to start applying some of my custom fixes/changes to the TRichView component. Other standard "diff" tools couldn't handle some of the changes that were made (various methods were moved around, so almost the entire file was different.). But the Structured Diff Tool easily detected these moved methods and only marked the code that was really changed. A *big* help and time savings for me. And my previous license was still valid, so it didn't cost me anything to get it working in Vista.

I sometimes forget how many different development tools that I had installed in XP and had forgotten about ;)

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

I've done similar when I've reloaded a machine. I'll think 'Okay, I only need to reinstall these handful of apps' and then I keep running into places where I'd forgotten something here or something there. I'm almost scared to think what would happen if I lost all of my Firefox extensions. There are only about 20, but a couple are non-supported ones which have been tweaked in order to work with the latest Firefox. They may be unsupported, but they work the way I want that type of plugin to work and I haven't found replacements which meet that criteria.

Posted: Fri Jan 25, 2008 10:05 pm

Only about 20!? I have four, and one of those is TalkBack. A lot of them were things I only used sparingly (NukeAnything) or were just for convenience and weren't actually that convenient (ForecastFox, FoxyTunes) so I didn't bother getting them again last time I formatted. I don't miss them.

Sorcerer Joined: 13 Jan 2006 Posts: 715

I'm only using MRTech's "About" enhancements, ForecastFox, FlashGot, MRTech XPI Delay Disabler, FireFTP, and UnPlug atm. Oh and TalkBack of course. However, of those, XPI Delay Disabler, UnPlug, and FireFTP don't really see much use.

I love my constantly updated weather, so ForecastFox is invaluable to me. I also use FlashGot to pass things to GetRight all the time. I was for a long time using a plugin for CSS enhancements too, that would allow me to extract CSS from any page and tweak it ;)

Anyways, thats all off topic rofl, but its one of the main reasons I love FireFox.

Still, if I had to ever redo all of my custom enhancements to my development environment, I would scream! Heh. I keep mine imaged, just in case.

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

Novice Joined: 26 Oct 2005 Posts: 32 Location: California

Posted: Mon Jan 28, 2008 5:49 pm

Yep, my BIOS does have the 'Legacy USB Support' and that option is already enabled. So that still didn't do it for me, although I still haven't checked this again since I added my USB 2.0 card to see if the problem still exists.

Posted: Tue Jan 29, 2008 12:51 am

Just a quick update for today. I'm finally into the "meat" of the conversion to Delphi 2007 today. I'm starting the process of copying over all of the CMUD source files and trying to get them to load and compile. There are several changes to properties in a couple of 3rd party components that are not backwards-compatible, which is causing me to need to edit the *.DFM form files in a separate editor to remove the bad properties.

There are lots and lots of forms in CMUD, so this is taking a while. I'm also trying to keep the new CMUD directory clean and only copy over the files that are actually referenced in the project. In Delphi, if you have a case of UnitA that "uses" UnitB, you don't need to add UnitB to the project's "list of units" as long as the *.PAS source file is in the search path. This is convenient sometimes, but when you get lazy like this, then your project's package list doesn't really contain all of the dependencies. This is one of the things I'm cleaning up as I go.

Today I got about half-done with this initial loading step. Tomorrow I hope to finish this step, and then I should be able to at least compile CMUD and see what is broken with the various 3rd party component changes.

But it's nice to be working mostly on my own code again instead of messing with Delphi 2007 and/or Vista.

Sorcerer Joined: 13 Jan 2006 Posts: 715

WTG! Zugg. That was a fairly fast convert for such a leap with such a complex project lol!

Posted: Wed Jan 30, 2008 12:38 am

Well, I wouldn't get *too* excited, because the hard part is still to come.

The Good News: I got CMUD to successfully compile within Delphi 2007 today. The not-so-good news is that there are several problems upon running it related to some changes made to 3rd party components. I'll probably spend tomorrow cleaning up the basic problems.

But the big hard job is the Settings Editor. I had made several changes to the DBTreeView from DevExpress so that it wouldn't constantly update itself when changes were made to the in-memory database. Rather than make those changes again, I want to take the time to look more closely at the design and see if I can use a standard TreeView and handle the database updating myself. This is a fairly big and scary project that could take a week all by itself. I'll have to decide later this week if I want to go ahead with that before or after I work on the MyMuds.com website.

Posted: Wed Jan 30, 2008 11:50 pm

As I expected, this is hard. Several annoyances so far:

1) Delphi 2007 made some changes to how database fields are stored in the form file, which broke the kbmMemtable version I was using. All of my database tables that I was storing on the form (creating small in-memory data tables) wouldn't load their data. I found an update to kbmMemtable that fixed this problem, and then I had to reapply some of my critical changes to this component (they still haven't fixed an obscure memory leak).

2) Delphi 2007 no longer allows the comparison:

if Char = '' then ...

to see if the Char variable is empty (equal to #0). A char value of #0 is no longer the same as the '' comparison, but the compiler doesn't complain about this bad syntax. The TurboPower XMLPartner components that I use for all of the XML parsing in CMUD has this comparison in several places. This is one of the components that has not been updated for Delphi 2007 (because TurboPower went out of business several years ago and posted all their source code to SourceForge). Once I fixed XMLPartner, then CMUD could load XML values (which is used a lot internally).

3) Delphi 2007 now checks for "valid" field names. When CMUD creates session-specific elements, such as the command line, it sets the component name to a GUID value to ensure unique component names. Well, the {} and - characters in the GUID are no longer valid component name characters. This is going to cause a problem and be tricky to fix because CMUD relies upon this naming convention when loading stored XLY and TBZ layouts to match the proper toolbar component with the layout saved in the file. So I'm going to need to strip the {} and - characters and then change my layout loading routines to strip these characters from existing XLY and TBZ files.

That's just the changes so far today. And I haven't found any of these changes documented anywhere, so they are pretty obscure. But these are the kind of annoying Delphi compiler changes that are driving me crazy because the compiler isn't generating any warnings for them. Hopefully I'll have more luck with this tomorrow.

But it's taking a lot longer than I expected to debug this kind of stuff. I haven't even gotten to the problems with the Developer Express toolbar system or the TreeView issues in the Settings Editor yet.

Posted: Thu Jan 31, 2008 9:26 pm

Now I'm into the hard part of this, and it's *very* frustrating. The new Developer Express ExpressBars v6 toolbar components are just as full of bugs as the previous version. Looks like they put all of their effort into implementing the stupid "ribbon" stuff that Vista uses rather than actually fixing the long-term issues in their toolbar design.

In fact, they've added even more bugs. None of the images in the command line for the Parse, Triggers, etc buttons will display because of a bug with how it handles dxLargeButtonItems that are placed directly on a toolbar (rather than within a menu). And there are new focus problems with the command line loosing keyboard focus whenever *any* menu or toolbar item caption is updated (like even the clock or the column number indicator).

I'm really not sure what to do right now. I really don't want to start directly modifying their source code again, because that will make it hard for me to apply updates when they fix bugs. I've spent most of the day so far sending bug reports to DevExpress about all of this stuff. And I'd like to stay current with their latest version instead of having to revert to their v5 component that they no longer update.

Unfortunately, I've searched, and there are not *any* other Delphi Menu/toolbar components that allow the end-user Customization that is such an important part of CMUD (well, even if people aren't really using the Customization options yet). I really like the feature that allows you to add your own buttons to the command line toolbar, and to drag/dock the command line toolbar or make it floating. So I really hate to give that up.

Why is it that I can mess with 3rd party components for only an hour before I find dozens of bugs? You'd think that a big company like this would have beta testers to catch this stuff. Sigh.

Posted: Thu Jan 31, 2008 11:21 pm

Looks like the solution to the issue with the toolbar buttons and the images not displaying is solveable without modifying their source code by developing my own "custom toolbar item". I should be able to copy their source code for their normal dxLargeButtonItem and make it into my own custom item and then fix it myself. This will probably take a day or two to get working, but should be a good solution.

In fact, this should allow me to properly implement additional customization options in the future more cleanly (like letting the user switch between large/small icons, etc).

The command line focus is more of a problem, but I have some ideas on how I might be able to force the keyboard focus back into the command line when another button caption is updated. Still need a bit more testing on that though.

I haven't tried to load the previous layout files yet...that's more work for tomorrow. Anyway, ultimately this will be a better solution. It's just too bad that they didn't support proper functionality out-of-the-box. Several people have complained about how their large icon/small icon support doesn't work in the new v6, but DevExpress just keeps saying stuff like "that is by design" and doesn't seem to be really listening to what their customers need as well as they should.

Posted: Fri Feb 01, 2008 5:53 pm

OK, I gave this a lot of thought last night and messed around a bit with "custom toolbar items". I've confirmed that this method will work and will be nice and clean. I also confirmed that I should be able to make my own TreeView descendant and properly implement the disconnected Tree component that is needed for the Settings Editor.

I also decided that this is the proper time to work on this kind of stuff. These kind of changes are important for the overall stability and long-term support of CMUD and are the kind of changes that are hard to implement during a fast-paced Beta-testing cycle because they are hard and time consuming. But since I am between beta cycles right now, this is the right time to do this difficult redesign work. Even though the results won't be readily apparent to end-users at first glance, getting this done right is important to the stability, and everyone agrees that is important.

So, even though it will delay the MyMuds project by probably another month, I'm going to go ahead and work on these changes so that I can produce a beta version for people to test while I work on the MyMuds site. Like I said, it will probably take several weeks to get this all working and to produce a new beta version. So I appreciate your patience, but I think everyone should agree that I should do this "right" and not just continue with kludging stuff like I tend to do when I get rushed during normal beta releases.

Posted: Mon Feb 04, 2008 11:46 pm

I made some decent progress today. I created a custom toolbar item for the regular buttons that fixes the bugs in how images work (large/small, top/left align). I've reported the bugs to DevExpress and have been working with them to try and convince them that these bugs really exist. I think they have finally acknowledged it, but it was like pulling teeth to send them demo projects to convince them.

I also looked into the "stretchable" command line item. CMUD currently kludges the command line to get it to take up the entire rest of the toolbar when you resize the window. DevExpress added a "Align=Client" property to their toolbar items, but it only stretches the item if it's the *last* item in the toolbar. That's pretty worthless, and certainly doesn't work for what we need with the command line (I also filed this report with DevExpress to request that they fix it so that it works for any item position on the toolbar).

But since I have learned how to create my own custom toolbar items, I created my own "Stretchable" item that works properly in any position on the toolbar. The really nice thing about this custom item is that it works properly when you add/remove items from the toolbar using the Customize command. It works *much* better than the current command line component, so all of the past problems with the command line disappearing should be completely gone forever now.

I think this takes care of the main issues with the Toolbar system so far. Tomorrow I'll start with my own inherited TreeView component to see if I can get that working better in the Settings Editor.

Posted: Tue Feb 05, 2008 11:46 pm

Today was a really good day. I think I have figured out how to do a "disconnected" TreeView using the existing DevExpress DBTreeView control without any changes to the DevExpress source code.

In CMUD, I had modified the DevExpress source code to add an "Enabled" field to the Tree. When this property was false, changes from the underlying database would be ignored. Then, a background timer refreshes the Tree data. The problem with this method is that the TreeView could become "unsynchronized" and then clicking on records in the tree could cause crashes. Trying to keep the Tree in sync was a major headache and resulted in a lot of kludged code.

Also, the DBTreeView in CMUD points to the main in-memory data table. This table (a kbmMemTable component) is used everywhere in CMUD to update the internal database. But when searching in the Settings Editor, or when just viewing a certain package, this database table would be "filtered" so that only the matching records would be displayed. This could cause problems elsewhere in CMUD when searching for records that were currently not visible in the filter. So I had to create an "attached table" which is essentially a separate cursor pointing to the same data. Each attached table can have it's own filter and index. So the main database could be filtered by the TreeView, but the rest of CMUD could use an unfiltered table to access the full database.

That's a quick summary of how CMUD currently works and some of the problems associated with it. Today I created a test program for working with the DevExpress DBTreeView component (with the plan to inherit my own custom TreeView component and then test it). But I just started with the "out of the box" DBTreeView to see what I could do with it. I created buttons to populate a database table with data, and to randomly change this data, so that I could see how long various operations took using the TreeView.

Delphi databases already have methods called "DisableControls" and "EnableControls" which toggles whether or not "data-aware" components (like the TreeView) should be updated. In normal database applications, when you are about to make lots of changes to the database, you call "DisableControls", then make the changes, then call "EnableControls" again. However, in CMUD the changes to the database can come from almost anywhere. Just changing the value of a zScript variable causes a database change. Putting DisableControls/EnableControls around this doesn't help if you are updating 100 variables in different places in your script.

So what I wanted to do was to "delay" the update of the tree view so that it only showed changes every second or so. But I couldn't just call DisableControls for the database table, because that prevents any other database operations from refreshing the database too. So that's why I had added the "Enabled" property to the TreeView...to simulate the DisableControls without actually using DisableControls.

Here is the trick: I create another "attached table" that points to the main in-memory database table. The TreeView displays this attached table. I immediately call DisableControls for the attached table. Then, every second, I call EnableControls and then DisableControls. Essentially, the database viewed by the Tree is kept disabled so that it ignores any database changes. But every second when EnableControls is called, the TreeView updates itself. Since we are disabling the attached table and not the main database table, the rest of the program is still free to update and change the main table.

The other trick is to turn off the "SyncMode" property of the DBTreeView. When SyncMode is true (which is the mode used in CMUD), clicking on a record in the Tree causes the database to seek to that record. And if the program calls DataSet.Locate or DataSet.FindKey, then the TreeView will automatically make the current database record the currently focused record of the tree. When DisableControls is called, the TreeView will no longer work when SyncMode is true. Clicking on a record in the tree will not focus it (because the database is disabled). However, if I set SyncMode to false, then I can freely select any node of the tree that I want, because it is disconnected from the current record of the actual database table.

I added a few other optimizations. For example, the 1-second background timer only calls EnableControls/DisableControls if it detects that there has been a change to the database. When Deleting record(s), the Tree is immediately updated so that you can't click on a deleted record. I also had to add some code to save/restore the currently expanded nodes since calling EnableControls can sometimes change what nodes are selected or expanded.

Finally, when updating the Tree, I can detect whether or not the record being changed is the current record being edited. If this is the case, the fields being edited by the user are not changed, and I've been able to re-implement the idea from zMUD where the "Refresh" button turns yellow to indicate that the data you are editing is no longer current.

However, this actually works even better than in zMUD. In zMUD, the Refresh button would turn yellow if *any* record has been changed. In this new CMUD TreeView, the Refresh button only turns yellow if the *current* record being edited has changed. So it's a lot more useful. Clicking the Refresh button will overwrite the fields that you are editing with their new values. But if you click Save Changes, then your edits will be saved over the new data.

I've still just got this in a test program. I've played with deleting records, adding new records, filtering data, and sorting data. It seems to work very well. I haven't gotten any crashes with it, and I've created in-memory database tables with 10,000 parent items, and 10 child items per parent, for a total of 100,000 items in the tree. And it's still lightning fast.

Tomorrow I'm going to go ahead and try to implement this in the real CMUD Settings Editor. I have to make a lot of code changes because the current Settings Editor all references the main in-memory database table, and I need to change it to reference the attached table used by the TreeView instead. It will probably take me a day to implement, and then a few days to test and debug.

But I'm *really* excited about this!! It's a lot better than trying to modify the source code and to use the TreeView how it was originally intended. This should result in a faster and more stable Settings Editor, without the huge job of writing my own DBTreeView component.

Posted: Wed Feb 06, 2008 12:41 am

I think practiclaly every person who uses CMUD has experienced some kind of problem, major or minor, with the treeview in the package editor. This is most excellent news.

Posted: Wed Feb 06, 2008 9:28 am

Yes it is, and the insight to the development of CMUD and just the way you deal with all the challenges of coming up with a great product is always good to know. Keep up the good work.

Posted: Wed Feb 06, 2008 11:32 pm

bah...I get one good day followed by another bad day.

I never even got to the TreeView stuff today. I got sidetracked by the focus problems with the command line. One of the *stupid* things about the DevExpress toolbar design is that changing the caption of any toolbar item causes the entire toolbar to be repainted, and this caused each "window control" associated with each item on the toolbar to be recreated. Thus, this causes the focus to be stolen away from the current control.

So, imagine typing on the command line with the clock activated. When the clock updates it's caption, the command line loses focus. Or, even worse, if you have the Column Indicator item enabled, then each time you press a key on the command line, the column indicator is updated, causing the focus to get lost.

I decided to make my own custom "label" item that preserves the focus when it's caption is changed. I thought this would be easy. DevExpress has consistently refused to change their design and to save/restore the focus, but they showed some code that the developer can use before changing the item caption to do this. But their code doesn't work...at least not with the way the command line works.

After several hours, I finally got a method that worked. It properly saves/restores the focus. However, then there was a new problem: when you give focus to a Windows EditBox, the contents of the edit box get selected. So, you might be typing in the command line, and then the clock updates, which saves/restores the command line focus, but now the command line is completely selected, causing the next keystroke to overwrite the entire command line contents!

So the next step was to save/restore the SelStart and SelLength properties of the edit box. This works a bit better, but it still doesn't restore the mouse dragging status. So if you are currently dragging the mouse to select some text when the clock updates, the mouse will stop selecting text. So this is still annoying.

I cannot figure out any way to save/restore the keyboard focus without these side effects. And I've been spending all day on this. The current CMUD actually has the same problem, but you don't notice it because the clock only updates every minute and not every second. And the Column indicator only updates when you are typing, so this doesn't effect any mouse selecting on the command line. But if you set up a Button and then Customize the toolbar to show that button, then write an alarm script to update the button caption every second, then you'll see the problems on the command line in CMUD 2.18 too. So I'd like to find a way to solve this once and for all. But unless I can find a Windows API routine that returns focus to an edit box without resetting it, I'm not sure there is any solution.

The problem is that the act of repainting the toolbar (which I understand is needed to show the new caption of the clock item), causes all of the Windows Handles for all controls in the toolbar to be recreated. So if you start selecting text in the command line with the mouse and the clock updates, then it's understandable that the mouse selection stops because it was previously selecting text in a window handle that no longer exists.

So maybe I can find a way to prevent the window handle of the command line from being recreated. But I'm not sure if that will be in any code that I have control over. But it sure is a pain to work on this kind of stuff!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I really can't understand why that is happening. I have written much simpler apps with a clock that updates every second and it doesn't have that problem. I can type in an edit box owned by the same window, one owned by a child window, or even another app and focus is not affected in the least. Same with mouse selection. It makes absolutely no sense that a repaint of a single item within a larger window would cause a change of focus. The are totally seperate entities.

I would have to say it is a bug with the DevExpress components. Although one of your previous posts made it pretty evident that they prefer to call thier bugs 'features'.

Posted: Thu Feb 07, 2008 12:43 am

Yes, I think it's a bug. I looked more into this and found that there is a method called "CaptionChanged" and it calls the bar's RepaintEx(true) method. The "true" is for the "RecreateControls" argument. Hmm, so what happens if I just change this to false? So I took my custom clock toolbar item and override the CaptionChanged method and call RepaintEx(false) instead. And guess what...now it doesn't recreate all of the controls and doesn't screw with the focus !!

BTW, keep in mind that this "clock" isn't just a normal label or edit panel. It's a widget on the toolbar. If I make a clock that just displays in a label then there isn't any problem. It's only when you update the caption of an item on the toolbar that any other toolbar item with keyboard focus loses it.

I think I have mentioned this before, but the root cause for this problem is the DevExpress design for their toolbar system. The way their architecture is designed, each item on the toolbar has a corresponding "control", which is the actual Windows control (like an Edit box for a BarEdit item, etc). They do not create these internal controls until the toolbar is repainted. It is the repaint routine that computes all of the sizes for the toolbar controls and creates the controls.

I don't know why they feel the need to recreate the controls all of the time...it's really insane. But consider the stupidity of this design: if you want to determine the width of an item on the toolbar, you first must call RePaint for it to get created and computed. In other words, you have to visually display the toolbar in order to determine the sizes of the items and then change them if you want to.

If *I* was designing this system, I would separate the visual part from the layout part and have a routine to just compute the toolbar layout without actually displaying it.

But DevExpress has had this stupid architecture for their ExpressBars suite for many many years. And now they are stuck in that position of having to maintain backwards compatibility for a stupid design. I can't really fault them for this...if they completely changed how it worked then they'd get a bunch of other customers screaming at them for not maintaining compatibility.

I had hopes when they announced that ExpressBars v6 wasn't going to promise full compatibility with the previous ExpressBars v5 (which is what is currently compiled into CMUD) that they might fix their underlying architecture. But they didn't. They just added Vista Ribbon support. v6 is really still fully compatible with v5. And most of the time when I make suggestions for improvements, they just say "we can't do that and maintain backwards compatibility".

Unfortunately, as I've also mentioned, the DevExpress ExpressBars system is still the *only* Delphi toolbar component that provides the advanced runtime Customization features that I want. In zMUD, for example, I used a different toolbar component called Toolbar2000 and TBX. But it was pretty basic in it's functionality and didn't have the runtime customization. The only other toolbar system I have evaluated is the AdvToolbar stuff from TMS Software, but they also don't provide runtime customization.

So, as much as I'd love to use something better, it doesn't exist (at least not for Delphi). So I am stuck doing all of these workarounds. In CMUD, I had just given up and gone into the DevExpress source code and changed it whenever I felt like it. But that has made it hard to upgrade and get bug fixes and support, so now I'm trying to only modify source code when absolutely necessary, and instead, try to properly create my own custom items that inherit from their existing items.

That's part of what makes this frustrating. I've "fixed" all of these bugs before in CMUD (by directly modifying their source code). But because I didn't think they'd ever release a new version of ExpressBars, I wasn't very good at documenting my changes/fixes. And their source code has changed enough that doing a "diff" finds tons of changes, not just the changes that I made. So, I'm having to fix all of these issues again, but do the fixes in a better way so that I'm not directly modifying their source code.

In this specific case of the command line, I spent many days in CMUD writing kludges to handle the command line stretching and focus issues. But none of that works really helps because I'm having to fix it in a different way now. I had just hoped that they would have fixed more of these issues. But now that I'm using their "out of the box" source code, at least I can properly report all of the problems to them. In the past I couldn't report many of the problems because I had modified their source code and couldn't prove the problem/bug wasn't caused by my own "fix". But now I can report everything...I've got dozens of open support requests with them right now. They are probably tired of hearing from me, but my current feeling is that I'm going to keep bugging them until they are sick of it and finally fix some of this stuff. Until then I can use the custom toolbar items that I've created.

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

You can get Tortoise SVN to tell you the differences between your modified code and the original V5 code (if you started tracking the V5 code when it was still unmodified) by right clicking on a SVN tracked file, go down to the "TortoiseSVN" submenu and choose "Show log". You can then see a list of times you modified the file. If for example you then right click on the first revision and choose "Compare with working copy" it will bring up a diff window showing you which lines of code you modified since you initially added it to SVN. That would let you find quickly where you modified their V5 source code and manually check it against the V6 and re-paste in the code where necessary.

If you didn't initially track the V5 code you can always create a new SVN repository in a new directory, add the unmodified V5 code, then paste your modified copy on top of that where you can then right click the modified files (with the red ! icon) and do a "TortoiseSVN -> Diff" to get the diff very quickly.

If you're feeling lucky, you can also try to auto-merge the two sets of code together by checking out the original V5 code into 2 separate folders. In the first folder, paste your modified source and commit it. In the second folder paste the V6 source, then perform a SVN update which should merge your modified source and their modified source together, and highlight any conflicting lines (ie lines which were modified in both your version and V6). Then once you've fixed that up you should be able to slot it back into CMUD and give it a whirl.

I'm still amazed at how these 3rd party developers get away with what they do, at my last job I was having to fix third party components and keep track of their changes vs my changes as they released new versions. Fortunately these guys don't seem to release new versions all that often, so a day spent diffing with tortoise is more of an annual thing. I'd be pretty upset if it was a monthly occurance though!

Posted: Thu Feb 07, 2008 6:03 pm

Yes, I know about SVN. I already use that for the differences most of the time. But there are a *lot* of differences because they moved stuff around in the source files. So almost the entire file is marked as different. I've been using a tool called ModelMaker Structural Difference which actually understands Delphi syntax and parses the file to determine the *real* differences between the files. This helps a bit more, but there are still hundreds of differences.

The problem is that the entire DevExpress toolbar system is basically in one big unit file (dxBar.pas). There is no way I'd try to "auto-merge" or anything like that with the large number of changes that were made.

Posted: Sat Feb 09, 2008 12:00 am

Still making progress. I got the Package Editor modified to use the new method of the disabled attached dataset. It kind-of works. Still lots of debugging left to do for next week. But at least it's displaying the settings and letting me click on items in the tree to show them in the editor. Adding an alias from the command line shows up properly in the tree view. Deleting an alias makes it disappear.

I'm still experiencing some performance issues during debugging. But I can't tell yet if these are because I'm using Delphi 2007 or because of Vista, or because of something I am doing in the code. But it seems to take a lot longer to create and display the edit panel on the right when you click on a setting. But I'm going to wait until I've debugged this and gotten it working better before I worry about that.

I got sidetracked for a while because the some of the in-memory tables that I use for lookups (like the table of variable types, trigger condition types, etc) were getting cleared out. I'd load them from my source file, and they would keep their values when I closed and opened the form in Delphi. But after running the application, the data would be cleared out of the form. In *finally* tracked this down to a "feature" in the new Castalia plugin for Delphi. This "feature" closes all datasets when running your application.

Now, this is normally a useful feature. If you leave a database connected normally, then it stores my test database locations, and when you try to run CMUD on your system, you get an error saying that it cannot open a database file. So for normal databases, it's important to have them closed when the application first runs. But the kbmMemTable has a feature that allows you to store data for a database table in the form resource. This makes it easy to create lookup tables of constant data (like variable types, etc) without creating a separate database file on the disk.

But these in-memory databases need to be kept open. If you close them when you run the application, then they lose all their data. And since Castilia was closing them automatically, they were losing data. After I turned off this feature in Castalia, then everything started working much better.

The command line is also working better. My new "stretchable" command line custom toolbar component is working like a charm. I've been able to turn off all of the kludges that I was using to resize the command line. The command line focus is mostly working, but I've run into a case now and then when it loses the focus and I'm still trying to reproduce that.

I also got the docking system to properly load the old-format XLY layout files, and got the ExpressBars v6 toolbars to load the old-format *.TBZ files. I'm still going to need to figure out how to override the "style" of the docking system so that it looks a bit better. I had modified the Delphi 7 version of the Docking components to use the Theme Engine. When I took out the Theme Engine, I modified the docking system to use the DevExpress "LookAndFeel" control (which is responsible for the OfficeXP "theme", Flat, UltraFlat, etc).

Anyway, now that I'm back to the "out-of-the-box" docking system, I don't really like it's normal color scheme. I'd like the tabs in the docking system to match the style of tab pages used elsewhere in CMUD. It looks like there is a way to create my own style for the docking, but I'll have to wait till next week to try and implement it and see if it really works.

My guess is that I'll spend all of next week debugging all of this and fixing various issues. If all goes well with that testing, then I'll do a beta release to let other people beat up on it.