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: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 )
EndExtern I 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 )
EndExtern or 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 )
EndExtern It'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 )
EndExtern But 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 )
EndExtern or: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 )
EndExtern both 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 )
EndExtern maybe 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
EndType Windows 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.
|