 |
slicertool
Magician
Joined: 09 Oct 2003
Posts: 459
Location: USA
|
 Posted: Tue Mar 01, 2005 1:30 pm
Easy export to Excel feature addition
|
When working with datagrids, a majority of people want to export into Excel for more in depth manipulation of data.
Excel has an extremely easy way to import data into it which is to markup a table of the information you want in standard HTML and then save the extension as '.xls'. You can also put in Excel formulas in the fields of your html table and Excel will process them as if they were created in Excel.
Just another cool feature for the zApp framework which shouldn't be too difficult to add in.
[edit: I was obviously much sleepier when I originally wrote this than I thought I was] |
|
|
|
|
theNerd
Adept
Joined: 01 Mar 2005
Posts: 277
|
Posted: Tue Mar 01, 2005 7:38 pm Exporting To Excel
|
I believe that the new grid Zugg is working with provides this ability built-in.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Mar 01, 2005 7:43 pm
|
Actually, the Grid I'm currently using does this also. And the new grid definitely does it. I just need to export the various methods that handle this.
As you might have noticed, there is a problem with zApp and methods. In Delphi, any *property* of an object is automatically described by it's "run time type information" (RTTI) so it's easy to access these properties from a scripting language. However, *methods* are not added to the RTTI. So, in order to call a method of an object from a script, I have to explicitly create the method interface for the internal COM object.
So, that's why you might have noticed that few objects have any accessible methods. It's a time consuming job to create all of the interfaces for the methods, and I've been waiting until I'm sure exactly what component set I'll be using. |
|
|
|
|
theNerd
Adept
Joined: 01 Mar 2005
Posts: 277
|
Posted: Tue Mar 01, 2005 7:51 pm
|
Perhaps you could create an app that scans the object's interface outputing the method wrappers so you can paste them into your delphi source code? This could speed up development.
In my experience with the scripting object all methods are added when using the AddObject method. Is this how you are doing it? |
|
|
|
|
theNerd
Adept
Joined: 01 Mar 2005
Posts: 277
|
Posted: Tue Mar 01, 2005 8:20 pm
|
I wanted to add some information to my post just so it sounds a little clearer. Using the msscript.ocx object there is a method called "AddObject" with three parameters (the last one is optional.) The first one is the name the object will be referenced as from within the script, the second is a reference to the object itself and the third is optional (because it defaults to False) and sets whether the members are added to the script. When the last one is set to True that means the script can access the properties and methods of the object directly without referencing them by name first. This is also a simple way of extending the scripting language.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Mar 01, 2005 8:33 pm
|
Actually, that's what I'm already doing. I have a helper tool that scans a Unit file and creates the COM interface for any public methods that I want. So, it's mostly a matter of putting the methods into the public area and then running this tool.
The part that is time consuming is putting the methods into the "public" area. With properties, Delphi is really nice and forgiving. If you have a descendant class, you can just say "property PropName" down in the published section and it will refer to the parent property. For methods it's a bit more ugly...you declare the method in the public section, but you still have to list the full argument list for the function or procedure. Then you need to create this in the implementation section and have it call the inherited method. For example, for each method I have to do stuff like this:
| Code: |
public
procedure ProcName( Arg1, Arg2: Integer);
...
implementation
procedure MyClass.ProcName( Arg1, Arg2: Integer);
begin
inherited
end; |
and that ends up being the time consuming part.
I know all about the AddObject method in the scripting tool. But this is designed to add a COM object to the scripting interface. Delphi objects are not COM objects normally. Many of them implement the IDispatch interface, but you cannot just add a Delphi object via AddObject and then call all of it's properties and methods. You have to create "wrapper" COM objects for this. You then implement the COM interfaces like GetIDsOfNames and Invoke to call the properties and methods of the Delphi object. You can handle all of the properties using RTTI, and the methods are handled by the interface object created by my tool that scans the original object unit file.
The other issue you have to watch out for when using AddObject is that there is no way to dynamically change this object, nor is there any way to delete it once it is added. In zApp, you are allowed to have multiple objects with the same name within different "scopes" (local, global, etc). zApp handles this again via the GetIDsOfNames and Invoke wrappers to determine what the *current* object of a given name within the current scope is. This kind of stuff can't be done with the normal MSSCRIPT object, which is why I have my own custom scripting host and don't use the Microsoft MSSCRIPT.OCX directly anymore. |
|
|
|
|
theNerd
Adept
Joined: 01 Mar 2005
Posts: 277
|
Posted: Tue Mar 01, 2005 8:34 pm
|
Zugg,
Okay, I just read your response to me on the other thread concerning why methods are not being exposed so don't feel obliged to respond unless you have something to add.
-Steven
Edited to Add: Whooops!! I was writing this post when I got a phone call so I didn't post this on time :-)
Also Edited to Add:
Quote: "The other issue you have to watch out for when using AddObject is that there is no way to dynamically change this object, nor is there any way to delete it once it is added."
You are so right!! Microsoft dropped the ball on that one!! |
|
Last edited by theNerd on Tue Mar 01, 2005 8:54 pm; edited 1 time in total |
 |
|
|
theNerd
Adept
Joined: 01 Mar 2005
Posts: 277
|
Posted: Tue Mar 01, 2005 8:38 pm
|
I understand now. I am primarily a VB, C/C+ and web developer and I am only familiar with the Pascal scripting language in InnoSetup. :-)
|
|
|
|
|
|
|
|
