Zugg Software :: View topic

Posted: Tue Mar 01, 2005 8:14 am

Now that I've got the email Cache object working for eMobius, I've finally got something that looks and feels like an email client. However, in getting in deeper with my current GRID and TREE components, I'm finding them very lacking in features that I need.

I've decided to go full steam ahead into the DevExpress component sets for Delphi. They have the best grid and treeview components on the market and offer the kinds of features I really want to use in eMobius.

The downside is that it will take me a while to integrate them into my "theme" system for zApp. Turns out their advertised "Look and Feel" system isn't as uniformly used in their components as they'd like you to think. And the ability to create custom look/feels is basically non-existent. Fortunately, it looks like they are calling the normal WinXP Theme routines, which I can intercept and replace with my current theme system. Several of the components are not painting properly so it is going to take me a few days to iron out all of the problems.

But once I've got the theme stuff working, the improved overall functionality of these components should help a lot. I've already tried their grid component in a sample Delphi app along with my database cache and it's much faster than before, and allows some really nice filtering and grouping options, which are key to some of my new email ideas.

Hopefully this will be worth the cost. The DevExpress component subscription was expensive, and their code does things differently than the "Delphi standard" so it takes a while to figure out how to use some of it. Fortunately this kind of stuff should be well hidden from zApp users. I should be able to swap components with very few changes to the zApp API interface.

That's the latest. I'm guessing it will take most of the week to get these components integrated into zApp. Once that is done, I'll probably do another Beta release of zApp so that the new database support can be officially advertised and marketed.

Geez, May is getting closer and closer. I wish there was some way to slow down the clock.

Adept Joined: 01 Mar 2005 Posts: 277

Zugg,

I am a professional developer who happened to stumble on your site. I was looking for something completely non-related to zApp but was intrigued by the concept of it because I had a very similar idea that I was going to program. Right now I am developing applications to sell through my company on the Internet. I got a zillion ideas (and more than one app going at once) so I am perfectly fine not pursuing the same idea. I am thinking that by using your app I could become a 3rd party developer if I can produce high quality apps quickly enough. I want to get some small but good quality apps that can make me money so I can go full-time on my business so I can finish my larger ones.

Here is a list of questions and suggestions. Please don’t be offended by any since I know a 100% how us developers can get stretched thin. I am a full-time developer and in my spare time I am writing my software to sell so I can go full-time with my business so I understand that there is only so much time in a day :-) Some of these are obviously “down the road” ideas:
* Going with the DevExpress controls is a very good idea. They are fast and function rich. I’ve played with them. I use Janus GridEx and Tlist 7 for my grid needs but I’ve been considering the XpressQuantumGrid (I also have Component Source’s from a subscription I bought from them but I never use them.) Unfortunately, your current grid is very slow so I would be eager to see you use the new one.
* Are all your object’s properties and methods fully exposed so that if I have an understanding of the component itself I can get more advanced? I know you are using the MS scripting engine, so you can simply expose the objects for direct access by the AddObject method. I understand that you would never want the responsibility of documenting any of them but if you were to let me know (even through email) what you are using I will find the documentation myself.
* It would be neat if zml apps created in zApp could function as web servers (just configure the port, etc.) and I could serve zml app to other users (esp. to other users of my apps.) There are several ActiveX controls for this. I could send you links to at least two if you want.
* If zApp (or will zApp) be developed so I can create more than one instance of the grid or treeview control?
* What are your plans for 3rd Party developers? I am considering becoming one if it meets my power needs (don’t worry, I understand what type of applications it’s tailored for.) I can create a dll in my own language and license that through eLicense and have some necessary function calls, etc. However, do you have a way for me to distribute the zApp editor? I don’t know if eLicense can do this, but if I created a Zugg approved dll that I license through eLicense perhaps a certain portion automatically goes to Zugg Software and the other goes to my company. I would hate to have to require a purchaser to go through that license process twice.
* Do you have resource usage and creation in zApp? If I want to distribute sounds and images, etc. I would prefer to load them from a resource file. Even if you implemented it through a SQLite database (I am working with that now) we could stream the information to and from that. Or that could be my eLicense DLL? :-)
* What dependencies are required for distribution? I am glad you no longer need ADO but I also know you probably require msscript.ocx, scrrun.dll, and probably the mcvrt dlls. But what exactly? Is there a minimum version of IE required?
* As far as skinning I use ActiveSkin (was $99) but it seems you can’t get that anymore. I recently came across another skinning component but it was quite pricey (compared to ActiveSkin.)

Sorry for so many questions but if zApp can help me get going with my business by getting some good quality apps created I would be very happy. I have 6 kids and one on the way (no kidding) so my time is precious. If you are interested, I would be willing to send you snapshots of applications I have created and am working on just so you know you are not wasting your time with me.

Sorry for the ramble but I am at work and I better get some work done. I will look for your reply.

Kind Regards,
Steven

Posted: Tue Mar 01, 2005 8:20 pm

Hi Steven,

Actually, this is great. It's wonderful to hear from another developer who is equally excited by this stuff. And it would be great to have someone really "pushing" the zApp technology and helping to test it for me. Let me try to answer your various questions (I'll number them to make it easier):

1) Properties and Methods: I actually just explained this in another post. But basically, any published *property* is automatically available since I use the Delphi RTTI stuff to link it with the scripting host. The *methods* are tougher because Delphi doesn't put them into the RTTI stuff. So I have to create COM object interfaces to handle the methods. I'm doing this slowly but was basically waiting until I really knew what components I'd be using. For the DevExpress components I expect you'll have access to most of the methods. When exporting methods and properties, I sometimes make some changes to make it easier to use in a scripting environment. For example, instead of passing object references, zApp often passes the Name of an object instead. This allows you to refer both to a COM object you've created and registered yourself, as well as some object defined in the ZML layout file.

So yes, you should be able to do some very advanced stuff with this one all of the methods are published. As far as documenting, you already understand this perfectly. It's a bit hard for me to completely document all of the components that I'm using...and some of them aren't even well documented. Even DevExpress doesn't have a ton of documentation. So, I'll be documenting stuff in stages, starting with high priority stuff that is zApp-specific. Low level documentation of each and every property and method will take a while. Fortunately, as I mentioned, if you are already familiar with the component I'm using, you'll be able to find documentation from the original component in many cases.

For example, the XML stuff in zApp comes from the open-source TurboPower XML Partner tools. They have excellent documentation for that already on Sourceforge.

2) Not sure what you mean by functioning as "web servers". I'm not sure the system is scaleable enough to act as an actual server of any kind. However, you mention distributing your zApp programs via a server and you can actually already do that. If you put your *.ZML file on a web server somewhere, than anyone with zApp can type:

zapp http://www.hostname.com/path/appfile.zml

and zapp will automatically download the zml file, then execute it locally. So yes, you can use this method to run or distribute applications remotely. zApp supports both the http and ftp protocols for this. It's actually something already built into the XML Partner components that I just mentioned.

Also, in the future you will be able to run multiple zApp programs at the same time, with only one copy of the runtime in memory. For example, I'm considering allowing stuff like:

zapp calc.zml editor.zml dbview.zml

which would run all 3 apps at once. In this regard, zApp becomes more of an operating system framework for executing applications. The problems will be that these apps all run in the same process space. The advantage is that multiple apps will be able to communicate easily with each other. The disadvantage is that one application could cause the entire zApp process to crash, bringing down the other apps too. In a way it's much like a primitive OS without all of the memory protection that we have these days with WinXP.

3) You can already use more than one instance of the tree and grid controls. There shouldn't be any limits to this.

4) 3rd-party developers: You've been doing your homework! It's good to see that you've already read about the eLicense stuff and DLLs. I really want to support 3rd party developers as much as possible. As you mentioned, you should be able to just eLicense a DLL file of functions required by your zApp program. What you need to do is buy the zApp Developer's Edition that allows you to convert text-based ZML files into encrypted binary ZXL files. Then you can distribute your encrypted ZXL file, along with your eLicense'd DLL file, along with the free runtime version of zApp. That will let anyone run your application without them having to buy zApp. The incentive for the customer is that if they buy the End-User edition of zApp, then they can create their own text-based ZML plugins for your app. Or, if you distribute part of your ZML files, they can directly modify your source.

So, the runtime version of zApp can be freely distributed with your programs, but it can only execute the encrypted ZXL files and not the direct ZML text files. This is essentially how Zuggsoft gets a part of the money. If a customer wants to customize or modify your program, then they have to buy the end-user version of zApp. And the Developer (you) need to buy the Developer's edition in order to create the ZXL files. Currently the Developer's edition is cheap, but as I add more of a graphical IDE to this, it will likely become more expensive.

5) Resource creation. This isn't documented yet, but zApp will always try to load a DLL file with the same name as your ZML application. For example, when you run the ZAPPPRO.ZML file, zApp automatically opens the ZAPPPRO.DLL file, which then causes the eLicense trial screen to be displayed for that DLL. In addition to handling the licensing, zApp will automatically look for image resources in this DLL file.

For example, if you have a button like this: <BUTTON Image="MYIMAGE"> then zApp tries to find an image in the following locations: First it looks for a file names MYIMAGE.GIF or MYIMAGE.BMP or MYIMAGE.PNG, etc. If a local file is not found then it looks for the resource named 'MYIMAGE' in the DLL file for your application. If this resource isn't found, then it looks for the resource in the main zApp.exe file. So, this lets you easily handle application-specific images by just putting them as resources into your DLL file.

I haven't set up any sound routines in zApp yet, but I expect I'll use a similar framework.

6) Dependancies: I'm attempting to remove all dependancies from zApp. As you mentioned, I just removed the ADO dependance, which is a huge relief! I don't actually use the Microsoft msscript.ocx file. I wrote my own ScriptingHost so that this isn't needed. zApp calls the Microsoft Scripting functions at the direct COM level, and I don't think you need the msscript.ocx for this.

If you use some of the local database access stuff, you might need the particular DLL for your database. For example, eMobius uses the SQLite engine for it's local email cache files, so I need to distribute the sqlite.dll file with eMobius. I'm not sure what scrrun.dll and mcvrt.dll files are used for. I'll do a check of what DLLs are getting loaded by zApp to see what it really needs. I don't think it needs anything that isn't a normal part of Windows. That's the advantage of using Delphi to create zApp. Even stuff like the PCRE library for regular expressions is compiled into the zapp.exe file directly.

7) Theming: I'm using something called ThemeEngine. The author has moved down a different development path, so I'm not upgrading this. The support for this is also minimal and the author got rid of his support newsgroup last summer. But the basic concept was to use existing WinXP theme files for skins. I like this idea, especially since components like DevExpress call the Windows Theme routines. So, having a library with a compatible interface with the WinXP theme engine makes converting 3rd-party components pretty easy. Unfortunately, the ThemeEngine code is full of bugs and I've been essentially rewriting it to try and make it work properly with the DevExpress components. ThemeEngine also comes with a lot of it's own components. The current version of zApp uses these, but the future version of zApp will be converted to all DevExpress components and will just be using ThemeEngine for the core skinning stuff.

Definitely feel free to post other questions, or send me email. Right now I am trying to stay focused on the eMobius email application. So, I'm adding stuff to zApp that directly impacts the eMobius development. This will continue through the summer. So, I'm not sure how fast I'll be at fixing other parts of zApp, or adding other components. But since eMobius is supposed to compete directly with MS Outlook, it needs to be a very professional application, which means that zApp will be improved and fixed to handle an application of that caliper. The fact that I'll be using zApp so much in my own work means that zApp should become pretty polished over the next few months.

Having another developer working with zApp like this will be a benefit to both of us I think. You'll be able to let me know what other areas zApp has problems in, and it will help me ensure that when I implement something in zApp it is of general interest and not just hardcoded for eMobius. But my priorities will still remain on getting eMobius to market this summer. And it sound like you are interested in zApp for the same reasons that I developed it, which is great.

Adept Joined: 01 Mar 2005 Posts: 277

>> zapp calc.zml editor.zml dbview.zml
I misunderstood what you meant at first and tried launching several zml apps simultaneously. Much to my relief it worked (could you imagine allowing only one zml app running at a time?) But I understand now. You meant you would like to add the ability to have several zml apps running using the same zApp instance?

I am going to purchase the End-User version tonight when I get home and maybe the developer version (that's up to my wife :-). I've spent so much money on development stuff that I have to run everything by her first. I've already talked to her about this and she sounds very interested.) I am wrapping up one of my commercial apps this week so I will probably play with it but I won't be able to get too serious until next week.

One last thing. How frequently do you release BETA updates? I am looking forward to the dev express controls.

Keep up the good work!!

Posted: Tue Mar 01, 2005 9:08 pm

Heh, I definitely understand. I just spent a ton of money on the full VCL subscription for DevExpress and that took a lot of guts for me to do, not to mention some explaining to my wife too. Fortunately, she understands what kind of stuff we really need for the business.

As far as releases, I've got a weekly build version that I'm uploading at this very moment. But like most automatted CVS builds, it's possible for there to be many problems with it. But it gives you the latest/greatest version.

For official beta releases, I usually do once a month or so. The next full beta won't be released until I've got the DevExpress components integrated (the weekly build doesn't use DevExpress yet, but has the Zeos database stuff). I am hoping to have the DevExpress stuff integrated in a week or two. I don't plan to take very long with this since I need to get back to eMobius work. But since eMobius needs the DevExpress grid and tree components, that will be my initial focus.

Also, you will find that I do my development in a very open manner. The tag line on the web site about "customer-driven Internet solutions" isn't just jargon...I really work like that. You are catching this at a very good time to have tremedous impact on how zApp is developed. While the first priority is for stuff that I need myself (I am desperate for eMobius...need to get rid of this Outlook crap), I pay very close attention to customer comments and feedback in these forums. Even if someone has an idea that can't be implemented right away, it usually stays in my mind and gets implemented down the road.

With the zMUD software that I've developed over the past 8 years, I'd say that 70% or so of the funtionality is based upon direct customer input. I expect this percentage to be just as high in zApp and eMobius. In fact, it was already due to some discussion of email clients in these forums last year which led to the invention of zApp and the idea of putting the user interface into an XML layout file.

Basically, the more deeply people get involved, the more rewarded they are with software that meets their needs. It's one of the parts of my job that I enjoy the most.