Actually, yes I would, except that I would catch the two external calls under one function as I already said. Script calls don't have the parameter limits that DLLs have. Creating windows objects isn't exactly time-critical, so one or two extra external calls do not matter. I also would not pass the window handle on every function call. It doesn't change, so you might as well pass it once on the initialisation of the library and let the DLL keep it in a global variable.
But then you have to keep the controls updated, especially progress bars, listboxes, treeviews, edits even maybe buttons.
Now imagine all those functions: set_bounds add_node remove_node add_item remove_item set_progress[_max/min] set_label... Few functions? Don't think so. I've developed this especially after seeing other winAPI dlls and their massive amount of calls and gml scripts.
Lastly, as to your handle thing, that wouldn't make any sense: how would you know which handle the particular dll call applies to?
The 'automatically handling events' is done by, once again, just programming what it does in Delphi. I still don't see why you wouldn't just compile it if you went that way.
I'm still asuming the user doesn't have a delphi compiler/IDE or that he doesn't know in-depth delphi. Therefor, the system for handling events in the interpreter is way better then what is implemented in other dlls, where only a set of messages/events (typically, the most used) are actually useable.
You bypass an iteration by spelling out the Delphi code instead. I still fail to see much difference. And you still have the same limits if data needs to be passed back.
Using strings, GM can store anything from whole objects to pointers. These could have been made by the delphi interpreter. Whichever the case, you can't do this in compiled delphi, because objects variables are static pointers and cannot be changed at runtime (eg, you cannot move an object into GM's memory).
I can't see what you refer to as the limit. I can't ever change GM's architecture, but I can make it simulate what it otherwise couldn't do. For example, if a Windows dll call fills a passed structure (like MEMORYINFO) GM can't do this sort of thing while the interpreter can pass such a structure (when it's fixed) and can format it into a string readable by GM.
I'm sure you've done your best in trying to attach the processes to the Game Maker window, but it's still a wrapper for an entire programming language. Of course RA can do all those things, exactly because it is based on a full-fledged programming language.
So what's the problem? Wasn't you fearing that I just wrapped it up and that's just it? I told you that I didn't *just* wrap it up, but I've changed a lot of things. For one thing, it required a different memory editor. Several objects needed changing because they didn't work right or had some features missing. For example pointer management needs some changing in the interpreter code.
I never said it wasn't.
So it's not level to execute_string()
. Just as
compiling java is not like compiling delphi (analogy).
Did you read the download instructions? It mentions that a prerequisite file must be downloaded and installed. And Codegears is the download host, not Borland. You might send them a friendly mail to ask where the download went, preferably not starting with 'Dear losers'.
Haha funny. Anyway, I don't see it worthwhile to get Delphi just for doing this. Now if it were in need of full-speed time-critical coding, then by no means I highly encourage it. But the problem is people wouldn't want to buy Delphi just for making a simple GUI dll.
Uuf, can you actually make documentation for the functions. I am really having a tough time with a few of them.
Sorry for that, but which are exactly problematic?
Kindly,
Chris.
