Register to post in forums, or Log in to your existing account
 

This forum is locked: you cannot post, reply to, or edit topics.  This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sun Mar 06, 2005 3:42 am   

Lastest info on DevExpress integration with zApp
 
Well, I've put in a *lot* of hours this week (about 60 so far) getting the DevExpress components integrated with the ThemeEngine stuff that is used in zApp.

It's become really clear that the DevExpress components are *very* well coded. I've only run into one actual bug, and it was very minor and easy to fix in the source code. They have a very complex and interesting architecture for their components, but once you understand how they do things, it all makes a lot of sense. The components are based upon a *much* more robust framework than the typical Delphi components, and do a nice job of providing compatibility with the native Windows API controls, while ensuring that they don't depend upon the buggy parts of the API, such as the COMCTRLS mess.

As a contrast to the well-programmed DevExpress components we have the ThemeEngine stuff. ThemeEngine was written by a Russian developer who has decided to charge for upgrades, and has abandoned attempts to support it. He took down his support newsgroups last summer and has refused to even set up a simple web discussion board. My opinion is that he's tired of hearing people complain about his code. Because the fact is, his code is really awful.

I have fixed *hundreds* of bugs in this guy's code. It barely resembles the original product anymore. What I've kept is the bare low-level engine that reads both Microsoft msstyles theme files, and his own KsDev .mskn theme files. I've got an interface to this low level engine that is compatible with the Microsoft uxtheme.dll interface. So now any program (like the DevExpress controls) that use uxtheme.dll to support Windows XP themes can use the ThemeEngine stuff.

Built-in support for Themes/Skins was one of the major design goals for zApp and I didn't want to give that up. Fortunately, the low level ThemeEngine isn't very complicated, and fixing the uxtheme interface to it (which was *awful*) has been mostly straightforward. It's just amazing how many routines he just never bothered to implement, or the poor assumptions that he made, or the brute-force style of programming he uses (lots of examples of the same block of code repeated over and over with minor changes, rather than using simple data tables).

The other part of the ThemeEngine was dozens of controls that the author wrote that used his ThemeEngine core. Stuff like his own Edit control, his own Button control, etc, etc.

What I've done is completely toss out all of his custom controls (Yeah!!) and am using the DevExpress controls instead. As I said, the DevExpress controls are very impressive and a lot more stable and bug free compared to the ThemeEngine controls that I was using in zApp.

The theme support for DevExpress is now working great. Every control, from their grid and tree, to their menu bar and toolbar controls, to their various edit controls, are all calling the ThemeEngine core and are working very well. Many many quirks in the previous ThemeEngine controls are gone now that I'm using the DevExpress controls instead. There were lots of little problems with various control painting that are all gone or fixed now.

In the entire process, I've only had to modify about 4 lines of source code from DevExpress. Then I replace their dxUxTheme.pas file with my own version that calls ThemeEngine. It's just as well that I never plan to upgrade ThemeEngine because I've changed that code so much I'd never be able to upgrade anyway. But since I *do* plan to stay up-to-date with DevExpress, it's nice that I needed so few changes to their code.

Well, a long post, but basically I'm still really excited about all of this. The improvement to zApp from replacing ThemeEngine with DevExpress is enormous, and that is going to be great for eMobius.

So, what's left? Well, now I need to rip out the ThemeEngine controls in zApp and replace them with the DevExpress controls. For example, the current zEDIT control in zApp currently descends from the ThemeEngine TeEdit control, and I need to change it to descend from the DevExpress cxEdit control. Then I update the properties and add the method wrappers. I need to do this for each and every zApp control that currently uses ThemeEngine (which is most of them). Then I'll replace the TMS Grid currently used in zApp with the DevExpress grid, and the VirtualTree control with the DevExpress tree.

My guess is that this will take several days. I will also be trying to document the new controls as I go. My current guess is that you'll see a new zApp release with all of the new DevExpress controls by Friday next week.

Making the DevExpress controls use ThemeEngine was the hard part. Lots of low level coding. Replacing the zApp controls with the DevExpress controls should be a lot easier. It will just take a while because there are so many controls to replace. But the work isn't very "brain intensive" compared to what I've done this week.
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Sun Mar 06, 2005 4:49 am   
 
Okay, I'm drooling. Cool Can't wait. This is going to be a slow week until Friday gets here... Sad
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Sun Mar 06, 2005 5:02 am   
 
Will zApp still run on Windows 98 with the new additions (for example, the theming?)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sun Mar 06, 2005 7:11 am   
 
Yes! That's the beauty of the solution. You'll be able to have themed apps on Win98 too, using WinXP theme files. The Microsoft Theme library is not required. So it will still work just like zApp does now.
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Sun Mar 06, 2005 7:19 am   
 
Awesome!! You deserve ice cream, cake, a cold beer and 2 hours of sleep tonight!! Keep up the awesome work!
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sun Mar 06, 2005 9:32 pm   
 
Only 2 hours? He's done such a good job he deserves at least 3 ... :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Mar 09, 2005 1:53 am   
 
ice cream?? cake?? What are you trying to do, kill me?

In fact, on Sunday I tried an experiment and had a slice of cake and a cookie for dessert to see how my body would react now that I'm doing the low-carb thing. Wow, what a mistake! I felt awful the rest of the day. In fact, I felt a lot like I used to all the time. And then I started feeling like I was coming down with a cold or something. This is bad!

Today I'm trying to ignore the fact that I feel lousy and see if I still have enough energy to program and stay focused. So far it's working. Even though I don't feel 100%, I was still able to program most of the day. I got tired after 8 hours, so I can't work 12 hour days like this, but the energy from the low-carb eating seems to be helping.

Back to the topic at hand, I have successfully replaced the Toolbar2000 (and TBX) components in zApp with the DevExpress ExpressBars menu and toolbar components. I tackled this first because I knew it would be the hardest. The ExpressBars components are *very* complicated, but also *very* powerful. They implement a lot of MS Office features, such as the ability to customize your menus and toolbars on-the-fly at runtime.

Since ExpressBars works quite a bit differently from Toolbar2000, I had to do a lot of internal changes to the zApp code. The objective was to maintain compatibility with current zApp menus and toolbars.

I've been successful at doing this! Most everything is working well and there are now a lot more options available for menus and toolbars. ExpressBars also contains some great docking controls, but I'm going to wait until I've converted the rest of zApp to DevExpress before adding those. These are the same docking controls that I'll eventually use to "fix" the docking in zMUD.

The runtime menu customization is very cool. The ThemeEngine integration is also working well with the menus and toolbars. The only thing that isn't working yet is that the customization dialog isn't using the Theme stuff yet.

Anyway, that's the latest. Now that the menus and toolbars are working, I'll start tackling all of the other controls, like Edit, Button, etc. I think I'm still on track for a release on Friday, but we'll see what happens with this cold and whether it goes away and whether I'm able to work around it like I did today.
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Wed Mar 09, 2005 2:43 am   
 
I am very much looking forward to the fruit of your labor! Although I'd love to see a new release by Friday I don't want you to work yourself sick. The low carb diet sounds like the best thing for you. It sounds like you might have insulin-resistance (like what I have.)

Anyways, I am looking forward to the newest version whenever it comes out.

Question: will zMud eventually be written in zApp?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Mar 11, 2005 12:05 am   
 
More progress to report here.

I have successfully converted the zEdit, zSpinEdit, zCombobox, zCheck, and zButton components from the old ThemeEngine controls to the new DevExpress controls. I also added a zRadioGroup component for radio button groups.

I added a new way to specify "subclasses" of controls. For example, in the past if you wanted to display a combobox filled with the fonts available on the system, you did this:
Code:
<COMBOBOX ... ListStyle='fonts'/>

This was a pretty kluncky way to handle it. While this syntax is still supported for backwards compatibility, the new way to specify a font combobox is with:
Code:
<COMBOBOX.FONTS.../>


So, I've added Combobox.fonts and Combobox.tables to the list of components. I still need to implement the Combobox.lookup using the new DevExpress controls.

I have also gotten the zGrid component working with DevExpress! It's still in it's early phases. There are some wierd things that I used to do in grid columns that still need to be handled, but overall it works. The DBVIEW.ZML demo application is really impressive now!

Currently I support two kinds of data in a grid...a) assign the DataSource property to display a SQL query in a live grid, or b) assign a zCollection object to the Collection property to display a list of collection elements, where each column of the grid is a particular field of each object in the collection.

I also plan to add a simple "array" mode that will allow you to directly access cells in the grid via a 2-dimensional variant array. Should be easy, just need to add the code for it.

Next on the list is to add back as many of the previous properties and methods as possible. For example, calling user-script routines to get custom cell data, etc. I'll probably spend the rest of the night doing that.

Tomorrow I plan to convert the zTree component to the DevExpress tree. Given how long this is taking, I'm guessing that the initial release of the DevExpress version of zApp won't be until Saturday. That will give me more time to tie up a lot of the loose ends.

Converting the Grid component was really fun and allowed me to learn much more about the DevExpress grid component. It's going to take a while to figure out how to let zApp users access all of the features that are available...it's a very complex component. But it has a really solid architecture that I continue to be impressed with.

That's the latest. Oh, you asked about zMUD being written in zApp? I doubt I'd ever do that directly...much of the zMUD code is so old that it would be hard to port. What is more likely is that I'll eventually write a brand new version of zMUD using the zApp technology, and call it "zMUD-XP" or something like that. I think I've gotten about as far with zMUD as I can with maintaining backwards compatibility with Windows 95 and with the old scripting system from the free version of zMUD. But overhauling the entire thing and writing something that was optimized for Windows XP (and beyond) might be fun. I'd have to make a version of the zMUD scripting language that ran within the Microsoft scripting engine, so it would be a lot of work. Not sure if enough people would buy it (I'd have to make it a new product to make *any* money on it at all), so right now it's all just a dream.
Reply with quote
slicertool
Magician


Joined: 09 Oct 2003
Posts: 459
Location: USA

PostPosted: Fri Mar 11, 2005 12:26 am   
 
I know I'd buy a new product line of zMud if it were an opimized from scratch technology. zMud scripting as an actual MS Scripting Engine compatible language would also be a cool feature for those of us that spend way too much time using your products Mr. Green
_________________
Ichthus on SWmud: http://www.swmud.org/
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Mar 12, 2005 3:06 am   
 
I got the zTree component converted today. I also added a new Database Tree component. You can either use the syntax:
Code:
<TREE ... DataSource='MyDataSource'/>

or the new subclass syntax of:
Code:
<TREE.DB ...DataSource='MyDataSource'/>

In the first case, if you omit the DataSource property, then a normal non-database tree is created with the same properties and interface as zApp used previously. If you omit the DataSource property in the second example, then a DB Tree is still created, with just an empty DataSource that you can fill in later via your script.

Once a tree is created, it cannot be switched between DB and non-DB mode. Unlike the flexible GRID component, the properties and methods for a DB Tree are significantly different than a non-DB tree (at least the way DevExpress implements it).

Since we never even had a DB Tree component before, this addition is a real improvement to zApp.

I'm really tired tonight, so that's about all I'm going to get done. Tomorrow I'll clean up a few loose ends, do a bit more testing, and maybe start documenting some of these new components. I'll do a release in the evening, even if it's just a "weekly build" release so that people can start playing with this.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sat Mar 12, 2005 10:25 am   
 
DB Tree components are a pain to write too, hehe, I wrote my own for work it sucks, maybe I should persuade the boss to buy this dev express,.. is it compatible with C++ Builder as well as Delphi?
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Sat Mar 12, 2005 4:45 pm   
 
I am pretty sure DevExpress's VCL components work in both Delphi and C++ Builder.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Mar 12, 2005 6:08 pm   
 
They have a VCL version for both Delphi and C++Builder. They also have a pure .NET version of most components for Visual Studio.NET. Can be a bit expensive, but well worth the price in my opinion. www.devexpress.com
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sun Mar 13, 2005 2:02 am   
 
I hate to post bad news, but I'm not going to get this released today. Some out-of-town guests arrived and I need to deal with them for the rest of the weekend.

It's frustrating because I'm *almost* done. I'm hung up on the Lookup Combobox for databases, as shown in the MAPVIEW.ZML demo program. Because I've been hung up with this, I haven't had a chance to clean up some other loose ends that I'd like to fix before the release.

So, rather than rushing something out that isn't very good, I'm going to wait until Monday when I have time to fix this.

One of the main issues I'm stuck on right now is something that has *always* been a problem with Delphi Combobox controls. When I assign the control to a field of a database, I'd like to populate the combo pulldown with string values, but have the INTEGER value stored in the database. So, if you have "Item 1", "Item 2", etc in the combobox, you store 0 for "Item 1", and 1 for "Item 2".

But the DevExpress DBCombobox doesn't support this. It always tries to store the string value in the field and then gives an error because the database field is an integer.

I'm guessing that I might have to modify the DevExpress source code, but I'd like to find a way to just inherit my own class and handle it there. Anyway, this is something I don't want to rush.

Sorry for those who were expecting the release today. But it reflects my normal design philosophy of not letting release dates force me to releasing something I shouldn't. Release dates are guidelines and not hard and fast deadlines.

Keep an eye on the forums on Monday for the latest update.
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Sun Mar 13, 2005 2:25 am   
 
No problem! Cool I'd rather wait and have something stable and more complete than have it rushed. Your design philosophy perfectly coincides with my own. Smile
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sun Mar 13, 2005 8:48 am   
 
The way I handled the DB Combo Box issues I had (and this is kinda a hack because I had to get 'em working fast) but what I did was store each entry as '<idnum>|<text entry>' ... then I wrote an ondraw handler to hide the id (or rather, only draw the text entry), and a get-value to extract that <idnum> as required...

Works, not necessarily that clean, but was practical enough ... also keep in mind that you might want to use a GUID instead of an integer as ID down the track (or shall I say if I was to ever use zApp for development I would expect it to support GUIDs), so don't necessarily build whatever you build to only be an 'int' field.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Mar 14, 2005 5:04 am   
 
You can already use a lookup box to handle complex situations like GUIDs. It is actually very powerful and just requires you to use an internal memory table for the drop-down box, and you can then relate any of this to the database and store whatever part of it you want. So the complex case is covered.

But I still want a simple case with a simple combo-box. A combo-box has two obvious possible values: The Text property that gives the string displayed in the control, and the Value (or ItemIndex) property that gives the position of the string in the list. All I need to do is modify the source code so that for Integer fields it stores the ItemIndex and for String fields it stores the Text. This is pretty straightforward, and I was kind of surprised DevExpress didn't already handle it (the previous ThemeEngine controls already handled this for example). I'll be sending them the mods so they can encorporate it into a future version.
Reply with quote
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion All times are GMT
Page 1 of 1

 
Jump to:  
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
© 2009 Zugg Software. Hosted on Wolfpaw.net