That's not what I meant. I mean a compiled library versus one interpreted on the fly: you can change your code at runtime. That's the major difference between having a compiled library and this interpreted one.
So you would prefer:
A basic difference is using one function while the earlier uses two (or a lot more for complex controls). By setting this code, GMRA can also be made to automatically handle events which in the case for other controls dlls you have to keep peeking at a message queue (not mentioning the multitude of other events that the programmer might not need).
But how does that differ from passing the required parameters down an external function call?
You can pass/store whole structures using strings and having delphi interpret it correctly. Of course individual parts of the structures may be read and sent to GM.
You'll have to explain to me what you mean here, it doesn't make sense to me.
Basically, it is a different event handling system which is controlled by the interpreter alone rather then having GM handle events by peeking using dll calls which is slowwer.
There still are free Delphi development environments. Such as this one.
I'd be weary about the license though...
Really, I don't see the problem here. Any parameters that you might want to change, you can pass through the DLL call. If one call can't specify enough parameters, nothing is stopping you from hiding two external function calls under a single script. Otherwise, it's not that difficult to have two development areas open at the same time, and apply your changes there where they are needed, and more importantly, where they are more appropriate.
It is a lot slower to execute a lot of dll<>gm calls rather then giving all the code/details in one string.
You do know Delphi is a RAD? Specifying interfaces in code would be a tiresome process. Delphi, as most RAD tools, allows you to design interfaces in a drag & drop manner.
So? That's another feature you're talking about there
because with the other dlls, designing a GM GUI is very hard. This one though is very easy. In fact I've been working on such a code generating RAD tool myself.
But this is not even the point. If you read all features you'd see the pending dfm parsing feature, which means yo can load dialogs from delphi DFM files.
But I can do that as well with a compiled library. Again I ask - if I am writing Delphi / Pascal code to do so, why wouldn't I just go ahead and compile a real library?
Who said you shouldn't? But for the less delphi-literate people around, they just want a working GUI with GUI coding only, not a dll with a lot of coding for simply managing the GUI, let alone the PChar/Memory Manager quirks and minor coding bugs in Delphi. Besides, as said, this is very useful for prototyping. If you get this working, then you ain't far from making a working model in real Delphi.
I didn't say it was any worse. There is a lot of rubbish being posted on these forums and it's easy to distinguish the admirable from the abject. It was unclear to me if there was merit or not in this one. For me, this looks like one of those libraries that came out some time ago and just wrapped an entire interpreter in Python or PHP (not sure which it was, maybe both were done).
And what if? Personally, I did take a certain commitment in this one, so comparing this with those might be a little of an insult. You can in essence run PHP code through the CMD or batch jobs, and who exactly would need Phyton, especially if it doesn't feature much out of the language core? This dll on the other hand features a lot of things including better support, a language very similar to GML, full windows control...
In short it i very much limitless. You want to get the harddisk serial? the number of devices? Manipulating an image quickly? An awesome GUI? No problem, RA can do it.
I'm afraid though that this time you're prejudicing this a lot.
I would have expected some encouragement from you.
Other then that, you know the features and you know your solid points. Please bring them out if any, and don't point at the obvious. I've stated above that this is a it slow, no point iterating over it. By the way, this is actually faster then GM's execute_string