Zugg Software :: View topic

Adept Joined: 01 Mar 2005 Posts: 277

Sorry, I couldn't think of a better title. Very Happy

I have a few questions and some suggestions. I hope you'll understand that in no way am I intending to pressure you. I just figure some of it will just be something for you to think about or to add to your list.

First off, I went through the tutorials and what I could with the documentation and I would like to congratulate you! I really found the concept of zApp to be logical and straight forward. As zApp comes together this will be really fun to work with!
1.zApp – pronounced z-App or Zapp?
2.Zugg - ??? Your real name???
3.Colorado – Actually considered moving there. I love the mountains!
4.Interesting idea of having your entire site in a forum :-)

Okay, more serious questions and observations:
1.This week you'll be posting the new version using ZeosLib. Will you have it so the new devexpress grid is data bound like the previous grid? If so, will it be bound to any of the database formats (SQLite, MySQL, etc.)?
2.With the new version of the database and treeview will the format for creating/using them remain the same?
3.Can or will you eventually enable portions of zml scripts to be compiled (encrypted?) My thoughts are, if I want part of the code to be editable but the rest protected and un-editable. I would like to preserve parts of code so, for example, I could retain access to the eLicense DLL and special functions. In fact, it would be good so that a zml app could be “bound” to a DLL so the user couldn't just delete or rename the DLL (there may be times where I just want access to it so I can create trials but may not actually be using any functions in it.)
4.I am not sure if this could be managed yet or not but it is an interesting idea. I would like to (eventually) make an app that could download new plug-ins directly from my site. Of course some or all of the plug-ins would have an eLicense DLL so they could use the plug-in for a limited time before being required to purchase it. This means I would have to download the zml and DLL (or an install that I download and automatically run.) I will eventually look into to this but I thought you might have a quick answer for this.
5.Not a pressure question, just want to know so I can plan what apps I am going to develop. How soon do you think you will incorporate sound and radio buttons and timers?
6.In a previous post I mentioned that I thought it could be useful to have a mini-web server built-in. There was actually a reason for this (and wasn't intended for heavy duty usage.) It was so a user could fill in information and HTML POST the data to a zml app on another computer that would get the data and put it into a database. It's for an idea I plan on doing (probably not as my first app, though.) I can create a DLL that will have some simple properties such as setting the Port to listen to, URLEncode, URLDecode, PageRequest event, onPost and various other simple events. If you know of a way I can do the same thing now in zApp let me know, otherwise, I'll just write the DLL. No big deal. :-)
7.It would be nice so that I could associate a file type with a zml or zxl so that when zApp opens the zml/zxl the app can open that file. Could you perhaps include that along with the ability (perhaps through an exposed object or string) the list of command line parameters?

Well, Zugg, thanks for your time. I'm sure I'll have other questions as time goes on. I really like zApp and your method of thinking is right up my alley.

Many of the ideas, I am sure, you will be putting on the back-burner until eMobius is done but I like to write them as I come up with them. However, your answers will help me a lot to plan what I will initially develop! The ZeosLib and the new grid and treeview I am counting on, the rest I am not. As far as the rest of the items the one that would be the hardest for me to implement myself would be the radio buttons. Ideally, I would like to avoid writing too many unique DLLs because I think this sidesteps the whole concept of zApp.

Adept Joined: 01 Mar 2005 Posts: 277

I wanted to add the fact that my wife loves the Theming ability. I have used the ActiveSkin in some of my apps and I find end-user's love it. I hope that when you get the time you do try and correct the bugs in it and don't decide to just stick with the windows themes. No rush on it, however, but I do like the feature. I looked up the site that sells the theme control you use and it says it can use over 1,000 themes. With ActiveSkin I am limited to what came with it because I definitely didn't have the time to create my own (although it could have some animations and fancy fade in and fade out effects over buttons.)

Posted: Thu Mar 03, 2005 8:31 am

Easy questions:

1) Either pronunciation is fine. I tend to say zee-app, but lots of others think it's fun to call it "zap", like "I'm going to zap an application now".
2) Nope, my online handle and D&D character name. If you explore some of the "About Us" links at the top of the site, you'll learn more.
3) That would be cool! If you end up really getting into zApp, it might be fun to have someone local. Anyway, we *love* Colorado and are here to stay.
4) Well, it's not really all in a forum. It's all in a MySQL database. The forum displays some of the tables, but a lot of other stuff (like the zApp docs) are in the Knowledge base, which is connected to the forums for the comments, but stored in different tables. Hopefully it looks mostly transparent to the user. I'm working on making the site more consistent all the time.

OK, now the more specific questions:
1) Yes, the DevExpress grid will replace the current zGrid and most of the zApp interface should stay the same. So, the method of connecting the grid to a database will be the same. And yes, you'll be able to connect the grid to *any* database. See the example in DBVIEW.ZML. The DevExpress grid should work exactly the same way, just with more features and much greater performance. I've played enough with the DevExpress grid so far to be *really* impressed with it's performance!

2) I'm trying to keep the zApp interface consistent. Of course, the current version of zApp doesn't export very many methods, so it will be pretty easy to keep the same interface with DevExpress. You'll see a consistent interface, and then lots more methods and properties hopefully. But this is subject to change since I haven't gotten into the DevExpress Tree and Grid details very much yet.

3) Yes, definitely. For example, see how the zAppPro application is set up. There is a plugin called zapppro_crypt.zxl. This is an encrypted plugin that calls my zapppro.dll file to perform the encryption. By hiding the details in the encrypted file, nobody can mess with it. See the zapp.Plugins article for more info on plugins.

4) Take a look at the Web Library description. You'll see a method called GetStream that lets you retrieve a file from a URL and store it to a stream (like a file stream). Eventually there will be a higher level component that does stuff like displaying a progress bar for downloading files, but for now the low level library routines should do it.

5) Timer and Radio buttons really soon...I need those soon for eMobius. I think there is already a way to simulate timers using the zThread object. Sound will be longer. Mainly because eMobius doesn't need it in it's first beta version, and also because I'm not really happy with the built-in sound interface in Windows. I'll probably do a "MediaPlayer" object pretty soon that just calls the Windows MCI system. But eventually I'd like to find a nice sound library to encorporate that has more power than the default MCI interface.

6) The current Web Library is based around the INDY Internet components for Delphi, and there are a *lot* of features in this. It is certainly possible to create various server objects that listen on ports and perform actions. So, this is possible, but not on a high priority list at the moment because it isn't needed for the first version of eMobius. But I'll see how easy a quick and dirty web server object might be.

7) Umm, the zApp installer should already have done that. Didn't it? You should have nice little "z" icons associated with both zml and zxl files. You might try downloading the Weekly CVS build from the download page since it uses the Nullsoft installer instead of the old crappy Wise installer, and I think the new installer is more reliable at creating the registry entries for the file association. But if it's not working, let me know. It's a bit hard to test here since I've already got the registry entries set up.

Also, in theory just running zApp is also supposed to set up the file association.

8) Themes: Yes, I'm fixing a lot of issues in the theming while getting the DevExpress components to work with it. So far it's actually going very well. I really love the idea of using existing WinXP theme files. I've got dozens of files that can be used with zApp. You actually have to run a conversion program to take a WinXP theme file and create the file needed for zApp. The conversion app, along with a simple ThemeEditor has been written by the guy who wrote ThemeEngine, and I'll be making those downloads available eventually. He doesn't provide the source code for the editor though, so we are stuck with a pretty basic program. But I've confirmed that you can take most any WinXP theme file and use it in zApp, and also tweak it with the editor. Also, because the zApp theming allows you to change the contrast and hue on the fly, you don't need a bunch of duplicate themes that just have different colors. I've seen several skin components that claim to have lots of themes, but then you find out there are really just a few with each one done in different colors.

9) Glad you are having fun with it. I'm really excited about this project and hopefully other people will eventually learn about it. Actually, I'd be interested in knowing how you came across it yourself. I have a marketing guy that is starting to work on getting the info out.

And yes, I'd wait a bit before doing too many DLLs. I release updates pretty quickly and it would certainly be wasted time to do something like radio buttons in a DLL. And you understand this exactly right...DLLs are there as a backup for people who have the full compilers that can create DLLs, but it sidesteps the whole idea of user customization. So, DLLs are a good place to put proprietary code, resources, and elicense stuff, but shouldn't contain the majority of the code.

OK, that's enough for tonight...time for bed ;)

Adept Joined: 01 Mar 2005 Posts: 277

Thanks for you answers!

As far as #7 I just wanted to clarify my question. Let's say I create a zxl file called MyProgram.zxl. MyProgram creates certain documents with an extension ".mp". It would be nice for me to be able to associate the ".mp" extension with MyProgram.zxl so that when the user double-clicks it, MyProgram.zxl automatically loads and then MyProgram.zxl loads the ".mp" file that was double-clicked.

Adept Joined: 01 Mar 2005 Posts: 277

Okay, I read the "About Us" - interesting. My younger brother was very much into MUDs and he wanted me to play them. There was only one reason I didn't - I knew I would love them and become addicted. I loved adventure games (even the old text adventures) and RPGs.

Do you like LOTR? Before I read LOTR I read Terry Brookes Sword of Shanarra which I really enjoyed. Of course, once I read the LOTR I found out how much of a rip-off his first book was of LOTR.

You asked me how I stumbled on zApp? Unfortunately, I can't remember what I was searching for (a component I think) and one link lead to another. Something about the description for zApp caught my eye and I followed the link to investigate. I wish I could be more help than that. I will give it some more thought. Maybe I'll remember then. I know Microsoft is talking XAML but I really don't want to go that route. I actually looked at developing in Delphi several times but when I saw they're taking the .NET route also I figured "forget it!" I don't want to have to rely on the end user having a huge .NET framework installed and I am not impressed with it anyways. At work some of our sites are being developed in ASP.NET (which is not too bad. it's really desktop .NET I don't like) and I will be forced to develop in it shortly (if I can't get my business going before then.) I believe zApp will have a good market even when XAML comes out.

After reading your answers and from what I've learned of zApp I am definately going to be a 3rd party developer. The first zApp I develop will be relatively simple but I have some very good ideas that I want to develop and will let you know about when it's time. The next while I am going to work at becoming fluent in "thinking" zApp development and whip together some little apps for fun.

Adept Joined: 01 Mar 2005 Posts: 277

Your documentation mentioned you have a resource of over 250 icons built-in to zApp. Do you have a list of those? Unless I was checking the wrong file my resource icon viewer couldn't read them (must be because of eLicense.) It will be nice to know what they are so all my apps look consistent.

Adept Joined: 01 Mar 2005 Posts: 277

Zugg,

I want to email you my idea for the first app. This way you can say if it will be possible when the new data grid and treeview are implemented or if I will have to wait for some of the functionality.

-Steven

Posted: Thu Mar 03, 2005 6:19 pm

Posted: Thu Mar 03, 2005 6:23 pm

7) You'd need to set up the registry keys for this yourself. Do a Google search on how to set up File Associations in Windows. You have to create a registry key that tells Windows what to run when you click on your ".mp" file. And then you have to create another registry key to associate an icon. You can use the REGISTRY component in zApp to do this if you want.

What you want to do is set up the .mp extension so that it executes:
ZAPP.EXE MyApp.zml

Windows can only associate a document with an executeable, like ZAPP.EXE, so you put MyApp.zml into the Parameter section so that when zApp runs, it loads your application. Now, the hard part is telling your MyApp.zml which *.mp file the user clicked on. Right now there isn't any way to pass command line arguments to your application. zApp will think you are trying to run multiple apps. So I'm still working on a reasonable syntax for having multiple applications on the zapp command line, along with command line parameters for each application.

Adept Joined: 01 Mar 2005 Posts: 277

bortaS,
Thank you for the links! It's good to know about those sites. I am going to take a better look at them later. I like the style of icons.

Zugg,
7) I pretty much assumed that would be your answer. If/When ZAPP exposes the command line parameters it receives then I'll be able to implement that idea. It is not necessary right away, anyhow.
10) Zugg, that was exactly what I was looking for.

I'm going to compose and send you an email in an hour or so.

-Steven

Adept Joined: 01 Mar 2005 Posts: 277

I read through the Plug-In information and some other documentation. Plug-Ins are quite cool. Next week (since I'll have more time) I will go through each item in the documention (fully documented or not) and play with it to try and get a good grip on zApp. I want to know it inside and out.

Zugg, hopefully you got my email and your spam killer didn't get it.

Magician Joined: 13 Oct 2000 Posts: 463

[quote=Zugg]I'm still working on a reasonable syntax for having multiple applications on the zapp command line, along with command line parameters for each application.[/quote]Perhaps you could have an either-or syntax?

ZAPP.EXE "foo.zml" -a -j --load "many parameters"

ZAPP.EXE /m "foo.zml" "bob.zml" "blinky.zml"

Being able to load many apps in a single line seems like a marginally useful task... it should require a command line switch (in my example, /m) to enable it. Being able to pass parameters to a loading app sounds like a VERY useful thing. It should be the default syntax.

IMO. MHO. Ok, MNSHO.

Adept Joined: 01 Mar 2005 Posts: 277

Raven, I agree with you 100% Smile

Posted: Fri Mar 25, 2005 12:06 am

Well, yes and no. Eventually I think you might find that starting multiple apps from the command line can be very useful. This let's zApp acts as a sort of virtual desktop for many applications.

The syntax I'm thinking of is something like this:

"string" represents the name of a zml/zxl file to load
-xxx represents an option for the previous file
+xxx represents an option for the previous file
/xxx represents an option for the previous file
/xxx="test" represents an option for the previous file.

So, your first example becomes:

ZAPP.EXE "foo.zml" -a -j /load="many parameters"

and in a more complicated example:

ZAPP.EXE firstapp.zml -a /opt="test" secondapp.zml -b thirdapp.zml

this would start 3 applications, passing -a and /opt="test" to the first one, and passing -b to the second one.

Basically, it's a free form syntax that recognizes that the name of an application will never start with a punctuation character, and using the = sign to prefix any plain text that should be an option instead of a program name.

How does that sound?

Adept Joined: 01 Mar 2005 Posts: 277

I still would like a way to associate a file with my ZAPP application. The only way to do this is to associate my custom extension it to a ZAPP runtime that is renamed (ex. MYZAPP.EXE) and then when it launches the associated ZXL file (MYAPP.ZXL or MYAPP.DLL with the ZXL resource) and then somehow read the command string from my ZAPP application. Would this be a possibility?

Posted: Sat Mar 26, 2005 6:21 am

You can still do this. Let's say your custom extension is .abc . You would create a registry entry for .abc and give it the following command line:

path\ZAPP.EXE myzapp.zxl /file="%1"

That would cause Windows to run ZAPP.EXE, which would then load my myzapp.zxl, which would then read the "file" parameter.

The reason I'm thinking of the syntax given above is that I want to do something more useful than just letting you grab the command line and parse your own parameters. I want to implement a couple of arrays:

core.OptionExists( "optionname")

returns true if the "optionname" appears in the command line in any form ( -optionname, +optionname, /optionname)

core.OptionValue( "optionname")

returns true if +optionname was specified, returns false if -optionname was specified, returns a blank string is /optionname was specified, and returns "text" if /optionname="text" was specified.

In other words, I'm tired of languages like Delphi that make you parse the command line yourself. Often when writing a program you just want to access the command line arguments with something like a Perl associative array, or just know if an option was specified or not.

Adept Joined: 01 Mar 2005 Posts: 277

That sounds very good! I like that idea!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Zugg, I love both the syntax for the command line that you describe and the built in parsing of options. I always hated writing command line parsing routines.

I have just one question. When launching multiple apps from a single command line will they all be done in a single instance of the zApp process? If they are then this allows a more modular design to building a complete zApp. Otherwise I wonder if some sort of notation would be available to facilitate data transfer between various zApp's.

Posted: Mon Mar 28, 2005 3:44 am

Yep, that's the idea. Right now each application uses a separate copy of zApp, but I'm planning to change this so that all applications (even if launched via different command lines) share a single copy of zApp in memory. In theory, you'll be able to communicate between different applications with this also. I'll followup with details once it gets implemented and I see how it works.

Posted: Mon Mar 28, 2005 6:28 am

I'm glad to hear that you're going to have them share one instance.. I was a little worried about the memory usage I imagined:)

Apprentice Joined: 11 Apr 2003 Posts: 119 Location: Sweden

You just have to be very careful about catching errors so that one app can't take down all other apps like IE, I always hated that stuff.

Magician Joined: 13 Oct 2000 Posts: 463

That works well... if a glob (%x in zmud terms) begins with punctuation, it's a parameter. If it begins with an alphanumeric or a quote, it's a zml file. I forsee no situations that would fail, unless you have zml files beginning with punctuation.

In which case you can mandate that they must be quoted if they begin with odd punctuation, and it still works.

Posted: Mon Mar 28, 2005 5:55 pm

Vodoc, that's the disadvantage. No matter what I do, if the applications are running with a shared version of zApp, there is no way to prevent one application from being able to take down another (or all of zApp for that matter). There is no such thing as bug-free code, and even if zApp was bug free, a severe memory problem in one of your own script files could cause the whole thing to crash. There is no way around this.

The only way to get around this kind of stuff is by writing an entire operating system like Windows XP that takes advantage of virtual machine features and which runs things in separate processes. That is way beyond the scope of zApp.

The main purpose of using a single copy of zApp is the memory savings. I'll likely implement an option where you can force a new copy of zApp to run for those cases where you want more application independance.

Adept Joined: 01 Mar 2005 Posts: 277

I like this idea, Zugg. Will all ZML/ZXL applications launched in the same address space be able to share objects and variables? That could be very handy.

Posted: Thu Apr 07, 2005 3:58 am

Yes and no. The scripting namespace wouldn't have all of the objects of any other application...there would be too much chance for name collision causing problems.

What I'll probably do is implement some sort of "core" function call...something like:

Set Obj = core.GetObject( ApplicationName, ObjectName)

which would return a reference to an object in another application.

The problem with this is that none of the scripting languages, like VBScript, ever delete any object references. So if you have a reference to some object in another application, and then the other application closes, if you try to access the object you will get an access violation. The same sort of problem accessing an object in a window that closes.

Using this mechanism you could share variables via the zApp VAR component. But you wouldn't have direct access to the scripting variables in the other application. Each application has it's own separate scripting host.

Of course, there's a really narrow distinction between an "application" and a "window" in zApp. You could just as easily open an "application" within a window within your own application, and then you'd have full access to everything in that window. There is already a core function called "OpenWindow". The second argument to this is optional but can specify the full ZML code to be used to load the window.

So, for example, if you have the code for a window stored in a file called WINDOW.ZML then you could load this file into a string and pass that string to core.OpenWindow. This has a lot of power for sharing code between applications, or generating windows dynamically.