120 replies to this topic

[uuf6429]

GMREC - Here's the right code which does what you assumed above.
Making a button in GM window:

// make_button(text)
// argument0 - text/label
// returns button ID
delphi_code="unit Button;

var Button1: TButton;

function Main: Integer;
begin
  Button1 := TButton.Create(nil);
  Button1.Caption := '"+Gml2Pas(argument0)+"';
  Button1.ParentWindow := "+string(window_handle())+";
  Button1.Left := 50;
  Button1.Top := 50;
  Button1.Width := 200;
  Button1.Height := 24;
  Result := Button1;
end;

end."
cvc_gmra_set(delphi_code)
return cvc_gmra_exec(global.RA_EXECUTE)

Removing a button from GM window:

// remove_button(button_id)
// argument0 - button id
delphi_code="unit Button;

procedure Main;
begin
  TButton("+argument0+").Free;
end;

end."
cvc_gmra_set(delphi_code)
return cvc_gmra_exec(global.RA_EXECUTE)

Examples (in GML):

// room start
global.b=make_button('Hello');
// room end
delete_button(global.b);

Enjoy!

Edited by uuf6429, 03 December 2008 - 10:01 PM.

[TheMagicNumber]

Thanks but I've noticed one terrible thing that you forgot. You never made any documents telling up how to use the DLL.

[icuurd12b42]

I found another quirk...

If you create a modeless form, dont set the parent handle to the game window, show it when the room starts, You close the game (The window still up or invisible, does not matter, but visible, you see it half drawn on the desktop), the form stays up and it crashes and GM does not come back...


However, if you remove
cvc_gmra_fini();

from the game end, it closes when you quit the game... And GM comes back

[uuf6429]

GMREC - I assumed it's very easy thus not much important to explain.
I think everyone here knows how to use those dll functions? If not check the script's comments and the helpfile in DelphiEditor (I think).
The problem you had, though, was because of the Delphi code not the GML usage. If you have problems with specific parts of the code please just ask.

icuurd - This problem is because the form was not freed. In delphi every object must be removed ( .Free() ) when you're not using it. The problem in this case is that the dll allocated/made that form and that script (cvc_gmra_fini) attempts to free the dll with the memory still allocated.
This "bug" is a clear indicator of badly written code. I'm not saying anything about you using this, because this thing is sort of too "Delphic" and GM works very differently.

In short, to fix this either Free the form at game end (before running that script) or make the object managed by another object. I will describe what I meant by the later option.
In delphi, an object can be connected to another one in two ways (typically); having a parent object and having an owner object. The parent contains the child (eg a button in a form) while an owner owns it (that is, deleting an owner deletes it's children). Deleting the form in the example above, the button won't be deleted. To set a parent, you typically use Parent or ParentWindow. The owner is the first paramater of the constructor (eg: TForm.Create(nil) ) it is usually nil, but you can set the owner.

In short, if you want that form to be automatically deleted use:
Form1:=TForm.Create(Application);
Application is an object which represents your program. It is created automatically. When the program ends, Application is automatically freed, thus it's childs which it owns (like this form) are also freed.

In my opinion, I prefer the method where you Free your objects at game end, it is much safer.

Regards,
Chris.


NB: In the next version there are several updates of major importance:
Interpreter: saveral fixes including pointer operations support, unit file loading, executing functions, weird bug found by icuurd
Memory: Now use FastMM4 memory manager, faster and fixes some bugs.
DelphiEditor: Instead of the GM example, a delphi one is going to be shipped (it's faster and much better) the demo source of the GM one will still stay there.
GMJCRA: Now features (an optional) error catching and reporting dialog.
Preview.gm6: Adds a set of scripts for easy control management, example GML:

f=ra_control_create("TForm");
b=ra_control_create("TButton");
ra_control_set_parent(b,global.CTRL,f); // set the parent; using control id (CTRL)
ra_control_set_bounds(f,20,20,640,480);
ra_control_set_property(b,global.STRING,"Caption","GMRA sucks, NOT!");
ra_control_set_bounds(f,20,20,200,24);
ra_control_show(f);

That creates a form and a button in it. Easy no?

Edited by uuf6429, 04 December 2008 - 09:57 AM.

[icuurd12b42]

Then I suggest you change your example code for the modal from example so you follow your own suggestion...
Form1.ShowModal;
Form1.Free; //<<--Missing

I don't free because, as you know, it causes an error which you told me will be fixed in the next release.
As soon as you put up the fix for the free on non modal forms which I reported earlier, I will have "not badly written code" and will be able to call finit when the game ends



Now, here is a few suggestions for examples.
Menu Example
ListBox/DropDownList Example
Scrolling Window Example
Docking Example

Also, an example of a container holding multiple classe(s) instances like an array or ds_list can hold object instances in GM would be cool.



Is there a way to have a window that stays on top of GM's window yet not have GM's window has parent? TopMost/ZOrder example

Edited by icuurd12b42, 04 December 2008 - 10:54 AM.

[uuf6429]

Form1.ShowModal;
Form1.Free; //<<--Missing

I thought I did do that... well sorry.

I don't free because, as you know, it causes an error which you told me will be fixed in the next release.
As soon as you put up the fix for the free on non modal forms which I reported earlier, I will have "not badly written code" and will be able to call finit when the game ends tongue.gif

Ok ok, no problem. What I only meant is that "bug" is only because of not freeing objects. The next version might even show a log of such unfreed objects.

Menu Example - Easy!
ListBox/DropDownList Example - Even easier!
Scrolling Window Example - Depends. You can have a TScrollBox which is like a panel but with scrollbars. But every form already support such a thing - just move child controls out of it (eg, form width is 200 and button left is 210)
Docking Example - Ok, but that can only work on vcl forms (not GM window), but you can still embed windows.

Is there a way to have a window that stays on top of GM's window yet not have GM's window has parent? TopMost/ZOrder example

Just set FormStyle to fsStayOnTop, but it would be topmost of every window (not only GM's).

Also, an example of a container holding multiple classe(s) instances like an array or ds_list can hold object instances in GM would be cool.

Not sure what you mean, but if I get you right, you can store Forms/Controls in a StringList ( IntToStr(Integer( TForm.Create(nil) )) ) and then only return the Id of the StringList to GM.

Edited by uuf6429, 04 December 2008 - 02:25 PM.

[icuurd12b42]

Docking Example - Ok, but that can only work on vcl forms (not GM window), but you can still embed windows.

I assumed I could place a docable form (A form that accepts docking forms) in the GM window that other forms will dock on...

Just set FormStyle to fsStayOnTop, but it would be topmost of every window (not only GM's).

Not really what I want, on top but not top most. I've done it in VB and c++. A floating window that can be anywhere, including outside the main window but still always visible yet not on top of any other application.

Also, an example of a container holding multiple classe(s) instances like an array or ds_list can hold object instances in GM would be cool.

Not sure what you mean, but if I get you right, you can store Forms/Controls in a StringList ( IntToStr(Integer( TForm.Create(nil) )) ) and then only return the Id of the StringList to GM.

An example of your Data Structure claim... in c++ like code it would be

class MyData{
public:
int count;
CString string;
}

Container Cont = new Container;
MyData *t;
t = new MyData;
t.count = 5;
t.string = "Element1";
Cont.Add(t);
t = new MyData;
t.count = 5;
t.string = "Element2";
Cont.Add(t);

int NumElements = Cont.Count();


I need this, personally, to setup a lot of data in a array or container when the game starts, to store all my data used by objects (including instance ID in gm) for my room editor... So that I can quickly change the display data of a properties window dialog so that I'll go back and forth from the form to GM as little as possible.

Thanks!

[uuf6429]

I assumed I could place a docable form (A form that accepts docking forms) in the GM window that other forms will dock on...

Yeah that sounds ok. Just not docking directly into the GM window.

Not really what I want, on top but not top most. I've done it in VB and c++. A floating window that can be anywhere, including outside the main window but still always visible yet not on top of any other application.

Hmm maybe ToolWindows? To do this change the form's BorderStyle property.

An example of your Data Structure claim... in c++ like code it would be

Unfortunately that's a bit buggy for the time being, I've even got to check it with FastMM. But it should be possible:

type
__MyData=record
____count:Integer;
____text:String; // string is a data type, can't be used as name
__end;

Edited by uuf6429, 04 December 2008 - 07:14 PM.

[TheMagicNumber]

Just set FormStyle to fsStayOnTop, but it would be topmost of every window (not only GM's).

Not really what I want, on top but not top most. I've done it in VB and c++. A floating window that can be anywhere, including outside the main window but still always visible yet not on top of any other application.

So you want it to be on top, or unable to minimize?

[Smarty]

Apologies for the sceptical note, but what is the advantage of this over, say, writing your own code in Delphi directly, compiling it and linking it to your game? If you need to write something in Delphi, you might as well do a real build and compilation, and end up with a library that is much faster, and much, much smaller. This DLL adds 1.4 MB to the game file.

The only difference I can see is that you can alter the code at game run, which makes it level to execute_string and execute_file... You don't gain much with data exchange, as you're still stuck with reals and strings.

[icuurd12b42]

Just set FormStyle to fsStayOnTop, but it would be topmost of every window (not only GM's).

Not really what I want, on top but not top most. I've done it in VB and c++. A floating window that can be anywhere, including outside the main window but still always visible yet not on top of any other application.

So you want it to be on top, or unable to minimize?

Yeah, a floating tools window usually can go anywhere... When outside the main window, they are on top of the main window but never intefere with other applications. They follow the zorder of the main window on the desktop while staying above the main window... When the main window is minimized, they usually hide.

Apologies for the sceptical note, but what is the advantage of this over, say, writing your own code in Delphi directly, compiling it and linking it to your game? If you need to write something in Delphi, you might as well do a real build and compilation, and end up with a library that is much faster, and much, much smaller. This DLL adds 1.4 MB to the game file.

The only difference I can see is that you can alter the code at game run, which makes it level to execute_string and execute_file... You don't gain much with data exchange, as you're still stuck with reals and strings.

Right now I am designing a UI with this. The advantage in my case is I can have dialog boxes and control them directly whitout going through any gm code. That is the code under the button on a form is still inside the context of the pascal interpreter... It's much more powerful than making a darn dll which you have no control over the forms/dialog boxes or the code that runs when you press a button or hover over it. You have full control like with a real programming language... Even the winapi dll has huge restriction on what you can do. This is like having all what GM missed for user interface coding.

It's more useful for UI design than API extention.

1.5 MB... I suspect uuf is distributing the debug version... Though I'm not sure which is his dll and which is ra. Still, 1.5MB is no larger in footprint than that of a large sprite many have in their game.

Edited by icuurd12b42, 04 December 2008 - 09:36 PM.

[Smarty]

Right now I am designing a UI with this. The advantage in my case is I can have dialog boxes and control them directly whitout going through any gm code. That is the code under the button on a form is still inside the context of the pascal interpreter... It's much more powerful than making a darn dll which you have no control over the forms/dialog boxes or the code that runs when you press a button or hover over it.

What do you mean? If you have Delphi you have all the control you need to create a DLL which has forms with underlying code. See here.

1.5 MB... I suspect uuf is distributing the debug version... Though I'm not sure which is his dll and which is ra.

Maybe, but keep in mind that a full Delphi interpreter might actually be rather large.

Still, 1.5MB is no larger in footprint than that of a large sprite many have in their game.

More like a large background, I think.

[uuf6429]

Smarty - I'll try to explain why it is any better:

Apologies for the sceptical note, but what is the advantage of this over, say, writing your own code in Delphi directly, compiling it and linking it to your game? If you need to write something in Delphi, you might as well do a real build and compilation, and end up with a library that is much faster, and much, much smaller. This DLL adds 1.4 MB to the game file.

Which means you have to get the whole delphi IDE (over 50 mb) and as far as I know there isn't a free version anymore. And no, it's not always smaller. Depending on the coding, the interpreter parses specific parts of codes while delphi keeps a list of all control configarution making it larger. As to speed, I asure you if it can run on a 1Ghz 256Mb RAM computer with no lag, then it's fast enough.
Besides, there are several advantages to recompiling. The system works on unlinked runtime packages meaning it can easily integrate into future OSes even non-windows ones.

As to the size, it does include certain debugging symbols but the interpreter alone only adds up 0.7Mb. Not much considering that a dll with it's forms may come well up to 0.7Mb, let alone more then one.

The only difference I can see is that you can alter the code at game run, which makes it level to execute_string and execute_file...

Not really. Can you compare running java with execute_string? Of course not with all the hype around java!

You don't gain much with data exchange, as you're still stuck with reals and strings.

Far from true. If you used it for a while you would see the demo were, GM can (via integers) control objects and pointers. This is much more flexible then the older system of playing about with a window handle.

One last thing, how can you see this any worse then the other API dlls? If anything it's much better, even faster and with more features.

You can if you want even call any other dll out there with it (of course at the moment there a small bug with pointers), but the idea's there.

For one thing, it can do a lot of changes in one GM<>DLL call where other dlls must pass like a dozen messages to do the same thing. Some parts of it are faster then the other dlls such as event handling which is direct in the interpreter rather then in a FIFO list.

Kindly,
Chris.

Edited by uuf6429, 04 December 2008 - 10:43 PM.

[icuurd12b42]

Right now I am designing a UI with this. The advantage in my case is I can have dialog boxes and control them directly whitout going through any gm code. That is the code under the button on a form is still inside the context of the pascal interpreter... It's much more powerful than making a darn dll which you have no control over the forms/dialog boxes or the code that runs when you press a button or hover over it.

What do you mean? If you have Delphi you have all the control you need to create a DLL which has forms with underlying code. See here.

You missed my point (I explained poorly). I don't want to get delphi, I don't have the money, I'm satisfied with FREE DevC++ and FREE Dev Studio for my dlls. Though I would have like to use Delphi to prototype my UI... I don't think 14 days will be enough...

If I'm going to build a dll to simply make a UI that I need to use in a GM game and call it from GM, It's never going to have a smooth enough integration as this provides. I would have to redo the dll every time I decide to change the interface. Adding the interface in GM... anyway. Too much trouble.

With this, All I need to do is run one piece of code to define and instanciate my entire UI which will run within it's own context, forms, code, UI logic and all... And peek at a few variable in the step event to make GM react.

My knowledge in Delphi is limited but I can make an interface typing code quicker and having a working UI work with this than making a UI a dll in c++ or using the dlls that we can find on the GMC.

And, this is a great way to quickly add any Windows functionality without having a multitude of dlls, File drop, Tray Application, Complex dialog boxes, scrollable lists with images, Complete Menu System, Scrollable properties windows, Docking Forms... Anything, on the fly.

And use DLLs that no one made a GM wrapper for yet. True, the extra layer will not improve speed, but in a jam, this can help a lot in that aspect.

On the first day of using GM, I was disapointed that I could not do ANY windows stuff on top of my game, Entering a name in a box that looks like crap was not my idea of an application that runs under Windows...Menus, Forms, Edit Boxes, Radio Buttons... All the standard windows features missing... This takes care of that.

1.5 MB... I suspect uuf is distributing the debug version... Though I'm not sure which is his dll and which is ra.

Maybe, but keep in mind that a full Delphi interpreter might actually be rather large.

Still, 1.5MB is no larger in footprint than that of a large sprite many have in their game.

More like a large background, I think.

Images in general is more what I meant.

Edited by icuurd12b42, 05 December 2008 - 03:46 AM.

[TheMagicNumber]

1.5MB, fairly slow (at the moment), but worth it.

[Smarty]

The only difference I can see is that you can alter the code at game run, which makes it level to execute_string and execute_file...

Not really. Can you compare running java with execute_string? Of course not with all the hype around java!

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.

Far from true. If you used it for a while you would see the demo were, GM can (via integers) control objects and pointers. This is much more flexible then the older system of playing about with a window handle.

But how does that differ from passing the required parameters down an external function call?

One last thing, how can you see this any worse then the other API dlls? If anything it's much better, even faster and with more features.

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).

You can if you want even call any other dll out there with it (of course at the moment there a small bug with pointers), but the idea's there.

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?

For one thing, it can do a lot of changes in one GM<>DLL call where other dlls must pass like a dozen messages to do the same thing.

But you must first parse a string to be executed in the interpreter. It seems to me it's just a replacement method of passing parameters.

Some parts of it are faster then the other dlls such as event handling which is direct in the interpreter rather then in a FIFO list.

You'll have to explain to me what you mean here, it doesn't make sense to me.

You missed my point (I explained poorly). I don't want to get delphi, I don't have the money, I'm satisfied with FREE DevC++ and FREE Dev Studio for my dlls. Though I would have like to use Delphi to prototype my UI... I don't think 14 days will be enough...

There still are free Delphi development environments. Such as this one.

If I'm going to build a dll to simply make a UI that I need to use in a GM game and call it from GM, It's never going to have a smooth enough integration as this provides. I would have to redo the dll every time I decide to change the interface. Adding the interface in GM... anyway. Too much trouble.

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.

My knowledge in Delphi is limited but I can make an interface typing code quicker and having a working UI work with this than making a UI a dll in c++ or using the dlls that we can find on the GMC.

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.

[uuf6429]

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:

b=make_button(window_handle(),x,y,w,h)
set_label(b,"Rubbish")

over:

code="unit temp;
function Main:Integer;
begin
b:=TButton.Create(nil);
b.ClientRect=TRect(x,y,w,h);
b.Caption='Rubbish';
end;"
gmra_execute(code);

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 .

Kindly,
Chris.

[icuurd12b42]

Smarty, you can't get that "Free" version any more... It eventually goes to the 2009 download 14 day trial version. At least for me since I am already a registered member for Borland C++... BTW, I tried to get that a few years back but Borland's free software was really odd. You had to choose between free C++, or Delphy or c# (I think). I chose c++. So I could not get Delphi too. One disables the other... Now you can't get it at all, only the 14 day trial is available.
[edit]
Wait, I managed to get through the clutter that makes you think it's no longer available... It's downloading right now... Just hoping they will send me an activation key though.

[edit2]
Well that was an epic waste of time and waste of bandwidth... The setup runs but the required components are not included and their download links are dead... GO Borland!!! (Loosers)

Edited by icuurd12b42, 05 December 2008 - 05:40 PM.

[uuf6429]

Too bad ...

Well there's still good ol' GMRA somewhere around.


Joking aside, this is a major version update including several fixes and exciting features. Please refer to main post for more details.

Kindly,
Chris.

[icuurd12b42]

___________________________________________
ERROR in
action number 1
of Other Event: Room Start
for object tester:

In script ra_control_set_property:
Error in code at line 20:
if (argument1==global.CONSTANT) then DelphiCode+=Gml2Pas(argument3);

at position 24: Unknown variable CONSTANT

___________________________________________
ERROR in
action number 1
of Other Event: Room End
for object tester:

Error in code at line 2:
ra_control_remove(global.listbox)

at position 27: Unknown variable listbox


I hope you have cool examples now.

I would spend a few days on making .pas files to demonstrate various ways of making a UI.

Since the error reports something about a listbox, I guess you added a few things since the last time....