In some situations (for example when interfacing with the winapi) it would be usefull to have something like c-structs as new variable data types in BMX. It could look like this:
however you already can allocate this memory from the stack with this workaround:
Also a nice feature could be to have something like static arrays like they are used in some win32 data structs, for example the ToolTip field in the NotifyIconData struct; to implement this struct as BMX type, you've currently to write something like this:
Just to make the difference clear between types/arrays and structs/static arrays:
The actual difference between a type and a struct is that when declaring a variable of that type you just have a reference to the object, a struct however would be a variable consisting of other variables.
The same with arrays and static arrays; a BMX-array is an object, so you also have a pointer to the object in memory; if you're using a static array variable in contrast you'll have a variable which directly contains the data.
So finally I just posted this feature suggestion here to hear some comments from you and BRL about how you think about it, and whether it could possibly be added to the BMX-language anywhere in the future.
Strict Framework brl.blitz Local Point:{ X , Y } GetCursorPos Varptr Point WriteStdout "Current Cursor Pos: " + Point.X + ", " + Point.Y + "~n" Extern "Win32" Function GetCursorPos ( Point:Byte Ptr ) EndExternI know it looks a bit like c-code, so it invites to write unreadable code, however when interfacing with winapi and c functions this can be usefull and much faster than you have to write now. Since we don't have something like structs we have currently to work like either this:
Strict Framework brl.blitz Local Point [ 2 ] GetCursorPos Point WriteStdout "Current Cursor Pos: " + Point [ 0 ] + ", " + Point [ 1 ] + "~n" Extern "Win32" Function GetCursorPos ( Point:Byte Ptr ) EndExternor this:
Strict Framework brl.blitz Local Point:TPoint = New TPoint GetCursorPos Point WriteStdout "Current Cursor Pos: " + Point.X + ", " + Point.Y + "~n" Type TPoint Field X , Y EndType Extern "Win32" Function GetCursorPos ( Point:Byte Ptr ) EndExternIt's a bit loss of speed, since the memory needs to be allocated from the system if you write the code this way - it would be faster if we could allocate the memory on the stack;
however you already can allocate this memory from the stack with this workaround:
Strict Framework brl.blitz Local Point:Long GetCursorPos Varptr Point WriteStdout "Current Cursor Pos: " + ( Int Ptr Varptr Point ) [ 0 ] + ", " + ( Int Ptr Varptr Point ) [ 1 ] + "~n" Extern "Win32" Function GetCursorPos ( Point:Byte Ptr ) EndExternBut this workaround can only help if your struct is 8 bytes or smaller in size - it can't fully replace structs, for example if you need a TRECT struct, which is 16 bytes long, till now you can't allocate this memory from the stack, so you have to write either:
Strict Framework brl.blitz Local Rect [ 4 ] GetWindowRect GetDesktopWindow ( ) , Rect WriteStdout "Desktop Resolution: " + Rect [ 2 ] + ", " + Rect [ 3 ] + "~n" Extern "Win32" Function GetDesktopWindow ( ) Function GetWindowRect ( Win , Rect:Byte Ptr ) EndExternor:
Strict Framework brl.blitz Local Rect:TRect = New TRect GetWindowRect GetDesktopWindow ( ) , Rect WriteStdout "Desktop Resolution: " + Rect.X2 + ", " + Rect.Y2 + "~n" Type TRect Field X1 , Y1 , X2 , Y2 EndType Extern "Win32" Function GetDesktopWindow ( ) Function GetWindowRect ( Win , Rect:Byte Ptr ) EndExternboth wouldn't be as fast and easy to use as:
Strict Framework brl.blitz Local Rect:{ X1 , Y1 , X2 , Y2 } GetWindowRect GetDesktopWindow ( ) , Varptr Rect WriteStdout "Desktop Resolution: " + Rect.X2 + ", " + Rect.Y2 + "~n" Extern "Win32" Function GetDesktopWindow ( ) Function GetWindowRect ( Win , Rect:Byte Ptr ) EndExternmaybe this feature request is a bit far away from the way BlitzMax is developed and designed by now, however this feature would help in some cases to do speed optimizing and easier interfacing with operating system's functions.
Also a nice feature could be to have something like static arrays like they are used in some win32 data structs, for example the ToolTip field in the NotifyIconData struct; to implement this struct as BMX type, you've currently to write something like this:
Type TNotifyIconData Field Size Field Win Field ID Field Flags Field CallbackMessage Field Icon Field Tip00:Long Field Tip01:Long Field Tip02:Long Field Tip03:Long Field Tip04:Long Field Tip05:Long Field Tip06:Long Field Tip07:Long Field Tip08:Long Field Tip09:Long Field Tip10:Long Field Tip11:Long Field Tip12:Long Field Tip13:Long Field Tip14:Long Field Tip15:Long EndTypeWindows defines that the tooltip must be placed directly in the data struct, so if you want to implement this struct as BMX-type you have to create 32 integer fields or 16 long fields (like in the code I posted); both isn't the best way to solve the problem - it would be much better if we could write something like:
Type TNotifyIconData Field Size Field Win Field ID Field Flags Field CallbackMessage Field Icon Field ToolTip:Byte { 128 } EndType
Just to make the difference clear between types/arrays and structs/static arrays:
The actual difference between a type and a struct is that when declaring a variable of that type you just have a reference to the object, a struct however would be a variable consisting of other variables.
The same with arrays and static arrays; a BMX-array is an object, so you also have a pointer to the object in memory; if you're using a static array variable in contrast you'll have a variable which directly contains the data.
So finally I just posted this feature suggestion here to hear some comments from you and BRL about how you think about it, and whether it could possibly be added to the BMX-language anywhere in the future.