Zugg Software :: View topic

Posted: Sat Apr 16, 2005 6:12 pm

We are getting closer and closer to the public release of zApp. Here are my plans for the next two weeks:

~~Finish documentation~~. Various components such as Image, Tabs, Panels, Threads, etc still need documentation. Also, I want to write a couple of articles on database programming in zApp, and how to use other scripting languages (with links to them) for Perl, Python, etc.
~~Events~~. I need to document the various events available in zApp (like OnKeyDown, OnMouseMove, etc) and I need to go through the code and make sure these events are consistently available for all of the components.
~~Command line argument~~. I want to implement the command line argument functions that were described in another discussion topic. This should also include the ability to run multiple apps within a single zApp instance.
~~zMemo file operations~~. The zMemo component still needs a few more methods for loading and saving files, and also dealing with inserting images.
~~zGrid exporting~~. I have some functions for exporting a zGrid to HTML, XML, and Excel that I want to add.
~~XSL transformations~~. I want to add the XSL methods to the XML library to allow you to transform XML into various other forms using a style sheet. This will be used to import XML data in various formats into database tables, and I'll be using it to capture XML from the zuggsoft.com knowledge base database to store in a local database to create a zApp documentation viewer program.
~~Panels~~. The zRaisePanel functionality needs to be added to the zPanel component. I also want to add the DockPanel components from the DevExpress window docking library [Edited: DockPanel will no longer be part of the first public release].
[Edited: No longer included in first public release] ~~Multimedia~~. I still need to add a library for interfacing with the Windows MCI multimedia API for playing WAV files, etc.
~~Installer packaging~~. Still investigating the best way to compress zApp and bundle various DLL files with the installer.
~~Bug fixes~~. There are still some bugs in the IMAP email demo application that I need to fix.

[Edited to strikeout the sections that are completed]

Stuff that I'm not going to get finished for this first public release are: printing (other than the existing printing support for the zMemo control), Windows ListView component, Grid "views", Graphics API access.

Still, it's a lot of work left. My current goal is to have all of this done by the end of April, which gives me two weeks of solid work. I still think I'm on target for that goal.

Please continue to test the latest build of zApp and post any bugs or suggestions to new topics in this forum. This is one of the best times to get tweaks or additions added before zApp goes public. Once the first public version is released, I'll be more concerned with backwards compatibility, but right now I'm still willing to change stuff as needed to make it easier to use.

Adept Joined: 01 Mar 2005 Posts: 277

#4 is an important one in my opinion. It will be used for report writing, mail-merge, etc.

Also, zApp can become a game maker using this ActiveX: http://www.spritecraft.com/ . This can be used in scripting languages and anything that can use ActiveX controls. It can be used free of charge in freeware applications. The source code can also be purchased. If I weren't so busy I'd do something with it in zApp just for the heck of it.

(I know Zugg is rolling his eyes at me right now. Rolling Eyes

)

Posted: Tue Apr 19, 2005 3:45 am

Interesting...any idea what language it's written in? I have plans for a sprite system eventually, but haven't had the time to look for something that does most of the work already ;)

And yes #4 is important. Also planned is a template system, similar to the template system that you can get for PHP. This should make mail-merge (and email clients ;) easier and more powerful.

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

Nice job so far.

The two components I notice not having are:
1) a picturebox control that you can draw on
2) a socket control

#1 I don't personally need right now, and I already have #2, so I'm not asking out of need but just because they seem to be standard components in visual tools these days.

-Tarn

Adept Joined: 01 Mar 2005 Posts: 277

Posted: Tue Apr 19, 2005 4:17 pm

Tarn: the (1) is what I meant about the Graphics API access that won't be in the public release. (2) might make it, depending upon the status of a surprise I have in store for people Cool

Posted: Thu Apr 21, 2005 11:16 pm

Wow, it's depressing coming back to this list to see how much is still left to be done.

I've got the new event model implemented, so (2) is basically finished, and that also took care of some documentation in (1). And (9) has been addressed by the new bulding software that I got. I've purchased this Bind2Exe software, but I haven't received my reg code from the publisher yet. So when you run zApp you get a popup about using an evaluation version of Bind2Exe. I don't want to upload a release until I get my reg code and can get this message removed.

I'm hopeful that I'll get my reg code and be able to upload the weekly build tomorrow.

Still at least a week's worth of work for the public version, but at least I'm still making positive progress.

Posted: Fri Apr 29, 2005 9:35 pm

Here's another update on the public version status:

(1) finished Panels, but still a few more topics to document
(2) complete.
(3) still needs to be done.
(4) complete.
(5) still needs to be done.
(6) still needs to be done.
(7) complete.
(8) still deciding what sound components to use.
(9) complete.
(10) still some bugs in IMAPMAIL that need fixing.

So, I'm getting there. Slow progress. Adding the Template system and Syntax Highlighting system to the zMemo component distracted me this week. But they were definitely worth the time. Once again, I think it's about a week's worth of work, so stay tuned next week to see if it gets finally released!

Posted: Mon May 02, 2005 12:25 am

I finished adding and documenting the XSLT functions in zApp today. Check out the zXSL component. In addition, the previous xmlDoc COM object has been replaced with the zXML component to make XML processing work a bit more like normal zApp components. The xml library functions didn't change, except that the SaveFile method got moved to the zXML.SaveToFile method.

I gave some thought to converting the SAX parsing of XML into more zApp components and getting rid of the various SUB OnXXX routines called by the SAX parsing. I might add a new component for this later, but for now I am leaving the SAX parsing alone since it works the same way that many people are already used to in ASP or PHP scripts.

If you haven't played with XSLT before, it can be very intimidating. I know that I'm *still* intimidated by it. One of the main needs for XSLT in zApp is the ability to transform XML data into a format that can be imported into a Data Set. This will be needed by the Documentation Viewer program to import the XML data taken from the Knowledge Base on this web site and importing it into a local SQL database.

In order to import and XML file into a database, the tags in the XML file need to be set to a standard set for creating new records in various tables, and adding field values to those records. So, I will probably create some additional functions and methods in the zXSL component to make these simple "copy and rename" transformations easier for novice users who don't have any clue about XSL syntax.

But for now, all of the normal XSLT syntax is supported, along with formatting objects for HTML, RTF, and XML. It's a very powerful system.

So, (6) is now partly done...I still need to actually write the documentation viewer program though.

Adept Joined: 01 Mar 2005 Posts: 277

My brother-in-law came into town with his family Friday so I won't be able to play with all the neat changes until Wednesday Crying or Very sad

As far as knowing XSL I am in the group of knowing what it basically is but I have never taken the time to learn it. I guess I've always needed to see an example of what real use it has before I took the time to learn it. I would love to see to an example of how it is used.

Posted: Mon May 02, 2005 5:27 pm

There is a quick example on the zXSL documentation page. I just got copies of the O'Reilly books: "XSLT" and "XSLT Cookbook". The main XSLT book has all the reference stuff for all of the various xslt functions and commands. The XSLT Cookbook is example-driven, and thats where I really started to learn more about how it works.

GURU Joined: 24 Sep 2000 Posts: 1237 Location: USA

Real use example:

Suppose you have a contact management system that you have to support on a web site for desktop users on high-speed connections, and on mobile devices with lousy connections. It's SQL based, consisting of multiple tables of related data (contacts, phone #'s, past orders, etc).

Desktop users on your high-speed intranet get to see contact pictures and order summaries together in a "richer" presentation that adheres to your corporate presentation guidelines.

Mobile users get just a text sub-set of the contact info so it's a smaller download, and since using some web conventions on a handheld device are clumsy, you list items as text links on a mobile, instead of drawing a 30-40 item-long select box like desktop users see.

If your SQL source returned data as valid, nested, well-formed XML, you don't have to write 2 business logic systems for working with it. Instead, you just write two XSL "formatting" cases for it: One for Desktops, one for Mobiles. Then your business-logic system works identically for both, the only difference being some detection of the end-user's device type, and a switch between which XSL templates you format with before you send them content.

Now when your business logic changes, you only have to change one "code" system (the handler) and maybe just make minor revisions to the XSL templates.

This example is contrived, of course, and it seldom breaks down as easy as it's painted to be. I created a system based on this premise and STILL ended up with separate business logic for both. Turns out the mobile users USE the data differently than the desktop users do, and require extra functionality that didn't make sense to combine with the desktop version. Furthermore, the XSL templates each used were colossal pains in the arse to create and maintain.

I recommend XSLT: 2nd Edition by Michael Kay as a decent (if stuffy) guide to learning and using the stuff correctly. Michael Kay is also the SAX author, btw. (Edit: Oops, no he's not... He's the author of saxON. Stupid naming similarities)

All that said, I've only recently seen a real-world use of XML data that exceeds performance and flexibility of non-XML equivalent systems. XSLT transformation of XML data tends to be slower (in my own experience) than the compiled business logic handling of it that turns out an equivalent set of data. XML's real beauty is in its sales pitch: light-weight, self-describing data structures compatible with any data system via simple (feh) XSL transformations.

That recently seen real-world use? http://maps.google.com - It uses XML to control what data/icons appear on maps. That's great for customizing it if you don't mind wading into the XML, but it sure seems like url-variables would be more straight-forward to me.

Adept Joined: 01 Mar 2005 Posts: 277

Thanks for the example, Darker. It clarified its use but also confirmed my suscpicion of it. Useful in theory but not the panacea that some may think. Definately has some uses in the right place, though.

Posted: Tue May 03, 2005 4:02 am

Or, think of the specific example that I added it to zApp for in the first place:

Imagine you have a SQL database out there on the web. It generates an XML data dump of selected records. Maybe this is a news feed, or RSS feed, or something like that. But assume that, unlike Darker's case, you don't have any control over this data format. It's in XML, but you are stuck with their choices for tag names.

Now you want to load this data into a local database. Your database can accept XML input, but it assumes that the tag names are the names of the fields in your database. Now, since you don't have control over the XML format being sent by the RSS site, the chances are high that their XML tags are *not* the same as your database fields.

So you have two choices: (a) create a different database with the proper field names, or (b) transform the XML data into the proper format for your database.

Obviously (b) is the correct approach in most cases. OK, so now you need to go through the XML data and change tag names, perhaps remove some field data that you don't want, and perhaps filter the records you really want to insert into your local database. Sure, you can write a program that will parse this XML file and convert it to the format that you need it.

The beauty of XSLT is that it's already a standard for doing just that. It specifies the transformation for converting an input XML file to any sort of output you want, whether the output is formatted HTML, RTF, or, in this case, another XML file with renamed tags.

So, there are a *lot* of uses for XSLT when working with XML. The problem is that I find the XSLT syntax to be a pain to remember. It's like learning the entire zApp component syntax, for example. Or like learning HTML for the first time. They have tons of tags that perform various actions on the input XML data, or perform various formatting of the output.

Does it take less time to just write your own program to transform the XML data, compared to creating the XSLT stylesheet? Perhaps. But at least with XSLT there is some chance of other people being able to use or modify your stylesheet, since it's a technology that people are really learning and starting to use.

It's sort of like using XML in the first place. After all, why output data in XML format in the first place? Why not invent your own proprietary dump format for your database? Well, people used to use their own file formats all the time. People are slowly switching to XML because it's flexible and other people are starting to understand it, and tools are being written to work with it. XSLT is like this too...there are several tools that make generating style sheets easier. You could even use zApp to write such a tool.

But when it came to writing something in zApp to transform XML data into a form that can be imported into an SQL database, using XSLT rather than creating my own customized data transformation package was a natural choice, and adds another feature to zApp that some people might be looking for in the future.

But I must say, it's definitely another great example of "design by committee". Some of the XSLT syntax is pretty obscure and obviously designed by web geeks. I was lucky that TurboPower had done an excellent implementation of both XML and XSLT before they went away and put all of their source code into the public domain. I would have *never* written my own XSLT system, that's for sure. But since it was already partially linked into zApp as part of the XML parsing, it made a lot of sense to expose it's interface to zApp users.

Adept Joined: 01 Mar 2005 Posts: 277

Your example is very good, too, Zugg. MS Office and other applications output their docs as XML. Although most of the info in them is not particularly transportable or useful, some of it is. I could write an XSLT style sheet to get some useful information out of them (for whatever purpose.) And since XSLT is a standard, another developer down the road could modify it to work with the latest versions of Office (or whatever.)

Thanks, it makes sense to me and I can see where it can be useful.

Posted: Tue May 03, 2005 11:20 pm

Getting this back on topic, I completed a lot more documentation today. So, (1) is basically done. All that is left to document is zQueue and zMessage and those will change when I'm working on eMobius soon, so I'm not going to document them just yet.

I also still want to write articles on database programming in zApp, and on various scripting languages, but I'm going to wait until after the public release to do that.

Adept Joined: 01 Mar 2005 Posts: 277

Posted: Wed May 04, 2005 7:22 pm

Yeah, the TurboSound stuff from the guy who does the Sprite system looks pretty good. I installed the demo today and it seems to work fine. So it's the best candidate for now, but I didn't want to rush in and buy something without looking around a bit more.

Posted: Fri May 06, 2005 5:57 pm

I've spent the last day or so looking into the Docking system from DevExpress, trying to see if I can implement docking panel functionality in zApp.

It's not going well. The docking system has several problems dealing with the theme system, and the general complex way in which the docking system is implemented doesn't yet fit the simple way I'd like to use it in zApp.

I'm going to end up having to implement my own custom docking panels that inherit from various DevExpress controls in order to make them a bit easier to work with. And this just isn't an important feature for the public version.

So, I've taken Docking Panels off the list of features for the public release.

All that's left now is writing the offline documentation viewer program, the command line parameters, and the bug fixes to the MailStore components that aren't working in the IMAPMAIL demo program (which is an important demo for me for zApp, so I need to get it working again).

Unfortunately, I'm not feeling well at all today. I think I'm fighting some sort of cold. So I'm going to try and take it easy this weekend and finish up the work on the public release next week.

Yeah, I know, it always seems to be "just another week". It bugs me as much (if not more) as it bugs you.

Adept Joined: 01 Mar 2005 Posts: 277

No problems here. I am very impressed with the progress you have made. Now get some good R & R!

Enchanter Joined: 10 Oct 2000 Posts: 698

Posted: Mon May 09, 2005 6:02 pm

Wow, Mr_Kent, what a thought-provoking post Exclamation

Income, (or lack thereof) is still a huge driving force, and a huge cause of stress. I've temporarily helped that by taking out a chunk of our retirement fund that I put money into back when zMUD was at it's peak. This has allowed us to pay some bills, and will help for a couple of months. Not a good long-term solution, but it has helped me focus on doing the "right-thing" with zApp and eMobius, rather than rushing to something because of the money.

On to the more interesting subjects: I can agree that I have *never* been in extreme programming mode this long ever before. And I think the low-carb lifestyle *is* a huge contributing factor. You mentioned the bursts of creativity that I used to get when I was sick...well, when I was sick, I wasn't eating carbs. I tended to not eat very much at all, and the little food that I did eat was typically high-protein (chicken soup, etc) and not sugar and carbs.

From a creative point of view, it's like I'm "sick" all the time now. Those flashes of insight and creativity come all the time and not just when I'm sick anymore. So I don't think we are losing out on anything...it's just the reverse. I'm in that creative mode all the time that I used to only get when sick or on vacation (on vaction I also tended not to snack as much and eat healthier, which is kind of strange but true).

Am I willing to try eating junk food again to see what happens? Absolutely not. In fact, the two times I have eaten more carbs, I have already gotten sick each time. The first time was over a month ago when I had desert at our local Sunday brunch buffet. I felt horrible the next day, like I was fighting something. This current bout of flu occured just a day after I decided to go ahead and have rice with my sushi last Thursday.

I'm not saying that eating carbs necessarily makes me sick...I think it just lowers my immune system and makes me more susceptible to catching something. Several of our friends have the flu and I just caught it. Would I have still caught it if I didn't eat carbs last Thursday? Perhaps. But it's interesting that the two times I have indulged in more carbs I have ended up getting sick and regretting it.

I think the answer to the causes of differences between zMUD and zApp development is: "All of the above". Remember that zMUD was written starting about 10 years ago using Delphi 1.0 on Windows 3.1. There were no 3rd party components...I had to write my own Windows Socket interface at that time. And Windows 3.1 was a horrible platform to develop on. The 16-bit OS had all sorts of memory restrictions, and networking wasn't built in.

That old legacy haunted zMUD for years, causing me to rewrite major sections of code. Over the years I upgraded to Delphi 3 and then Delphi 5, and eventually got rid of the 16-bit restrictions in zMUD v5.x. But it became a mess of code and backwards compatibility support.

Also, at the beginning, nobody knew what a MUD client should really do. Whereas zApp is a development environment, and I've used enough development environments over the years to know more about what it should do. So it has been easier to do a more complete design of zApp. zMUD never had an initial design...I just started coding.

And yes, the development tools and 3rd party components have improved tremendously over those 10 years, and I'm a much more mature developer as well.

Your comment about sickness striking at the end of release time is interesting. I haven't thought about that much, but it does seem to be true. Maybe there is something in my mind waiting to bubble to the top like you said. I'll have to think about that some more.

I'm feeling a bit better and hope to be back to programming tomorrow. But thanks again for the thought-provoking post.

Adept Joined: 01 Mar 2005 Posts: 277

Zugg, I've been blown away by your productivity and progress on zApp. I know you are anxious to get this done and eMobius done but I think the zApp development has gone quite smooth. Although we are sure to find bugs as we go along I have found it to be very stable.

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

Beginner Joined: 24 Mar 2005 Posts: 16