02 December 2013

Using methods and properties through IDispatch

This is all about two – more or less – undocumented features; the GFA-BASIC _DispID() function and a special dot-curly operator, the .{dispID} syntax.

An object’s layout in memory is, when using a BASIC Object variable data type:

MemObj vtable (array of function pointers)
AddrOf vtable AddrOf QueryInterface()
RefCount% AddrOf AddRef()
…. AddrOf Release()
…. AddrOf GetTypeInfoCount()
… data AddrOf GetTypeInfo()
  AddrOf GetIDsOfNames()
  AddrOf Invoke()
  AddrOf ComPropertyMethod1()
  AddrOf ComPropertyMethod2()

After the following commands the BASIC Object variable oIE holds a reference to an instance of Internet Explorer, an automation server and therefor guaranteed to support a dual interface.

Dim oIE As Object
Set oIE = CreateObject("InternetExplorer.Application")
Trace Hex(Long{V:oIE})
Set oIE = Nothing

An Object variable is actually an Int32 data type and holds the address returned by CreateObject.
Initially, the Object variable is zero (or Null) and is interpreted as Nothing. The following statement does nothing more then checking if the variable oIE holds a value (is not zero):

If oIE Is Nothing Then _
  Debug.Print "No Object assigned"

To view the contents of the integer oIE we first needs its address. In GB32 you can obtain an address of a variable in several ways. You may use VarPtr(oIE), or V:oIE, or *oIE. After obtaining the variable address it must be read, or peeked, to get the contents. Reading a Long or Int32 from some address is done using Long{addr}. The Trace statement uses the Hex function to convert the value to a hexadecimal format, the usual format for a memory address.

From the previous blog post Using OLEVIEW we learned how to process the calling of a property or method through late binding. To summarize, to execute a method or a property of the object an automation client can:

  1. Call GetIDsOfNames to "look up" the DispID for the method or property.
  2. Call Invoke to execute the method or property by using the DispID to index the array of function pointers.

All BASIC languages support this behavior behind the curtains. They provide the object dot-operator to call properties and methods through late binding. For instance, when you want to check to see if Internet Explorer is visible you may call the Visible property:

If oIE.Visible == True Then _
  Debug.Print "Is visible indeed"

After compiling this code the program will execute oIE’s interface-function GetIDsOfNames to "look up" the DispID for the property. It will then generate code to call Invoke to execute the method or property by using the DispID to index the array of function pointers (vtable). Calling Invoke is a bit of a hassle and is best left to the compiler.

Now what when the server gets new functions and new names. Unfortunately, you would need to recompile and redistribute the client application before it would be able to use the new properties and methods. In order to avoid this, you could use a ‘CallByName’ function to pass the new property and method names as strings, without changing the application.

In contrast with other programming languages GFA-BASIC features a function called _DispID(). This function allows you to call the objects GetIDsOfNames function to "look up" the DispID for the method or property. When you remember the blog post on Using OLEVIEW you might have noticed that every property and method is assigned a unique ID (integer value). Using _DispId(0bject,Name$) we can obtain exactly that unique value. For instance, this will display the ID value 402 in the Debug output window.

Trace _DispID(oIE, "Visible")

Obtaining the dispId of a method or property is only useful when you can use the integer value to call the IDispatch function Invoke(). Specifically for this purpose GFA-BASIC 32 provides us with a might piece of equipment; the dot-curly operator. To call Invoke using the dispId you can simply replace the name of the property or method with ‘{dispId}’.

Global Long dispIdVisible
dispIdVisible =  _DispID(oIE, "Visible")
Trace oIE.{dispIdVisible}
Trace oIE.{402}

How does VB6 do it?
If you’re interested, you should compare this elegance to the VB6 function CallByName. This function allows you to use a string to specify a property or method at run time. The signature for the CallByName function looks like this:

Result = CallByName(Object, ProcedureName, CallType, Arguments())

The first argument to CallByName takes the name of the object that you want to act upon. The second argument, ProcedureName, takes a string containing the name of the method or property procedure to be invoked. The CallType argument takes a constant representing the type of procedure to invoke: a method (vbMethod), a property let (vbLet), a property get (vbGet), or a property set (vbSet). The final argument is optional, it takes a variant array containing any arguments to the procedure.

Due to the elegant syntax, GB detects how to invoke the method or property. The parameters of a property or method don’t go in a Variant array. Due to the dot-curly syntax the parameters are specified as any other property or method call. The only thing you need to do yourself is retrieving the dispID, but this is of great advantage since now you are able to store the ID to use it over and over. The CallByName() function each time has to obtain dispID for the name passed.

Dlg 3D On is for Dialogs only

GFA-BASIC 16 (for Windows 3.1) offered the command Dlg 3D On. to get more appealing 3D effects for dialog boxes and controls. This command was invoked before a dialog box was defined and/or created, which was the same thing in GB16. Usually the command Dlg 3D On was placed at the start of the program so that all dialogs would benefit from the 3D effect. In the background the 16-bit system CTL3D.DLL was loaded, was responsible for the painting.

What is CTL3D?
The 16-bit CTL3D.DLL hooks into dialog creation and control creation and "subclasses" the standard windows controls to give them a more appealing 3D effect. To draw 3D effects the background of the dialog boxes was painted gray, or more precisely, painted using the COLOR_BTNFACE color. That made the 3D effects possible in the first place.
This technique was first used by Microsoft Excel version 4.0. The Excel team shared the technology with the rest of the industry. Since then, the use of CTL3D has become a de facto standard and is commonly used by professional Windows applications. GFA-BASIC 16 supported the use of this DLL directly using Dlg 3D On/Off.

Still present in GB32
Starting with Windows 95 a much more pleasing 3D look is provided by default. This made CTL3D unnecessary. Despite its absence in Windows 32-bits GFA-BASIC 32 still supports the the Dlg 3D command, for backwards compatibility. However, its implementation is quite different now. The 3D effect is not accomplished through a system DLL, but by setting the default background color of the dialog box to COLOR_BTNFACE.

Dlg 3D On only works for Dlg form Ocx objects, these are the forms created using the Dialog # / End Dialog commands and accessed with the object variable name Dlg_n, where n is an ordinal value between 0 and 31.

Starting with GB32 most attributes of windows and controls are managed through OCX properties and methods. Internally, all window management is routed through the COM wrappers of the system OCX controls. This is also true for the creation of Dialog # forms. The runtime runs exactly the same code as when you create an Ocx Form. Other (16-bits compatible) window commands like OpenW, ChildW, and ParentW are created by this code as well. However when a Form is created using the Dialog command, the runtime code converts the Dlg 3D and  DlgBase Xxx commands to the appropriate Form-Properties.

Dialog # id, x, y, w, h, tit$ [,flag [,height,font$] ]

The attributes of a dialog form may be set beforehand using the following commands: 

Command Meaning
Dlg 3D On Fills and sets background with COLOR_BTNFACE
Dlg 3D Off Use default Form background-color (default)
DlgBase Pixel Use x, y, w, h as pixels (default)
DlgBase Unit Use x, y, w, h as dialog base units
DlgBase InSide Use x, y, w, h as client size
DlgBase OutSide Use x, y, w, h as window outside (default)
DlgBase Font font$ Use font$ for all controls
DlgBase Bold Use a Bold version of font$
DlgBase Bold Off Use a Normal version of font$
Dlg Fill Fills and sets new background color

The font$ parameter overrules the DlgBase Font setting.
Afterwards the background color can be changed by using properties or by using the Dlg Fill command.

These Dlg commands are used in conjunction with Dialogs only.

30 November 2013

Using OLE/COM Object Viewer

Ever wondered how to get information about all properties and methods of the GFA-BASIC 32 OCX COM-objects?

To view GFA-BASIC OCX type library information, you can use the Microsoft OLE/COM Object Viewer utility that is included with the Microsoft Windows SDK kits.


The figure displays information from the GfaWin23.Ocx type library, a resource found in this DLL. More specifically, it shows the details for the Form Ocx and the CurrentX Get Property. You use the OLE-COM Object Viewer to view compiled type library information. The object viewer presents the COM classes in C/C++ syntax.

To view a type library with the OLE/COM Object Viewer:

  1. Find the OLE/COM Object Viewer application in the bin directory of the installation path.
  2. On the File menu, click View TypeLib, and browse to locate the type library you want to view (GfaWin23.Ocx)

Like the Object Browser that VB and Microsoft VBA use, the OLE/COM Object Viewer lists all the classes exposed in a type library, along with the methods and properties those classes support. For the programmer, the OLE/COM Object Viewer provides important information, such as function return types, argument types, and DISPIDs (which will be discussed shortly). You can use the information that the viewer provides in conjunction with the GB32 object model documentation.


Download SDK
The latest Windows Software Development Kit for Windows 8 (Windows SDK) contains headers, libraries, and a selection of tools that you can use when you create apps that run on Windows operating systems.
The Windows Development Kit (SDK)

I also advise to read Automating Microsoft Office 97 and Microsoft Office 2000 to refresh your memory on the binary layout of COM objects. You may take a look at the section “How an object can exposes its methods and properties”. It does so in two ways: by means of a dispatch interface and in its vtable. Also take a look at my blogs Build a COM object in GB32 (1) and    CreateObject.

A COM object exposing its functions through a vtable only, provide clients with early binding only. The compiler binds methods and property invocations to the vtable-function-pointers directly for more direct access and faster execution. An object that exposes its methods through both a dispinterface and its vtable supports a dual interface.

The DispID
You can examine type libraries in the OLE/COM Object Viewer to determine if an object provides a dual interface. An object that provides a dual interface specifies the dual attribute in its interface declaration. All GB32 OCX objects implement the IDispatch interface. It is this IDispatch interface that provides Automation clients with access to an object's content and functionality. An object's methods and properties collectively make up its dispatch interface (or dispinterface). Within the dispinterface, each method and property is identified by a unique member. This member is the function's dispatch identifier (or DispID).

A COM object can provide clients access to its functions using a dispinterface, an array of function names, and an array of function pointers that are indexed by DispIDs. In GB32 the execution of methods and properties through the dispatch interface is hidden behind the COM dot-operator on an Object data type. First see how GB32 executes properties and methods through early binding.

' Create new instance of the ImageList OCX.
' The Iml variable is of COM type (I)ImageList.
Dim Iml As New ImageList
' Access through early bindings; call the
' ImageHeight and ImageWidth directly through
' a function pointer.
Iml.ImageHeight = 16
Iml.ImageWidth = 16
Iml.Add  , "comp", LoadPicture(":MyComp")

See also: Dim As New

As you can see from OLE-VIEW, the IImageList interface is declared dual. So, the properties and methods are available at runtime as well (late binding). The GB32 compiler doesn’t put a reference to a function address, but stores the name of the method or property and the values of the parameters that must be passed. The compiler than inserts a call to Invoke() to have the program call the method or property at runtime by looking up the name of the function through GetIDsOfNames(). You may want to read the section on Binding in the same article Automating Microsoft Office 97 and Microsoft Office 2000

Note It is a VB/VBA convention to use the name of an interface a a new user-defined type and than skip the capital I from an interface name. So, IImageList in OLEVIEW becomes ImageList type in BASIC.

Now let us see how the method and properties of the ImageList type can be executed at runtime through late binding. The general BASIC Object data-type is an object consisting only of the IDispatch functions. The Object variable oIml doesn’t know about other interface functions ImageList supports. The compiler inserts code to execute the function .Count at runtime through the IImageList functions GetIDsOfNames and Invoke.

Dim oIml As Object      // An IDispatch object
Set oIml = Iml          // Assign to Object
Print oIml.Count        // late binding

To execute the Count property of the oIml object must call GetIDsOfNames to "look up" the DispID for the property. Subsequently, oIml calls Invoke to execute the property by using the DispID to locate the Count function address in the IImageList’s array of function pointers.

Next blog: GFA-BASIC 32 supports syntax and functions to look up the DispID and use Invoke.

06 October 2013

Debug is a runtime object

Closer examination of the Debug object reveals some interesting facts. Although the GFA-BASIC IDE offers some alternative actions to open the debug window, it is not an object owned by the IDE.

The Debug object is completely embedded (data and methods) in the GfaWin.Ocx, which is GFA-BASIC’s runtime. The Debug object is not dynamically created like other COM objects. You don’t use the Ocx command or a New clause in a Dim statement. The Debug object is a global (static) object located in the data section of the DLL. Other examples of static runtime objects are App, Screen, Printer, Forms, and Err.

Note – Most COM objects are – by nature – dynamically created at runtime. In GFA-BASIC they are either allocated using the Ocx (or OcxOcx) command, or with the New clause in a Dim statement. These commands create and allocate memory on runtime. Like the String datatype, a COM object is always stored and accessed by a pointer. A COM object variable occupies only 32 bits and points to a block of memory allocated from the free store. When the variable contains the value 0 (not pointing to a memory address) the object is said to be Nothing. There are some more functions that implicitly create dynamic COM objects, like LoadForm and LoadPicture. Each COM object created by a GFA-BASIC command is destroyed by GFA-BASIC, whether it is a static object or dynamic object.

The Debug object manages the window
Thee Debug object isn’t allocated at runtime, it is available all times. You can immediately start invoking properties and methods on the Debug object. Although the purpose of the debug output window is to display state information at runtime, the Debug object is mainly used to control or manage the debug output window. The debug output window is a modeless, top level, non-owned window with one child control; a standard EDIT control. Many properties and methods control the appearance and behavior of the debug output window and/or its edit control. For more information of the properties and methods look at the descriptions in the help-file or press a dot after the Debug keyword in the editor. Most of them speak for them selves.

Like your application can use the Debug object, the IDE can use the output window as well. The IDE uses the same static Debug object as your application. Any changes the IDE makes are reflected in your application, and vice versa. For instance, when the IDE hides the debug output window, your application must re-show it explicitly.
The IDE offers you two alternatives to show the output window.

  1. By selecting the IDE menu bar View | Toggle Output Window [Alt+3] at design time.
  2. By selecting the tray icon popup menu item at run-time.

Your application can provide its own means of operation to open the debug output window. The debug window could be used for logging, without actually showing the window.

So, whether your application or the IDE controls the debug output window, they both use the same static Debug object in the runtime. Therefor it is important to know what happens in the background.

The Debug thread
First of all, at the first opportunity – when one of the Debug object’s properties or methods is invoked – a new thread is created. As with all good threads it is not destroyed before the application ends; that is when the DLL runtime unloads from memory. When the GFA-BASIC IDE starts executing the thread isn’t started immediately. Only when your GFA-BASIC application, a GLL editor extension, or one of the IDE commands to show the debug window, are applied the thread is actually started.

The debug thread registers the DebugClass window class and creates an instance of the window class (top-level). Note that the window is displayed in the taskbar. Once the window is created the thread enters an infinite message retrieval loop (inside the thread) and handles the dispatching of messages to the DebugClass window procedure, located in the runtime. The window procedure itself is responsible for responding to the messages of the debug output window. One of the messages the window procedure must handle is the WM_SYSCOMMAND, because the debug window thread adds a system menu item to the window (Always on Top). The window procedure either responds by setting the top-level window to the top of the top-level-windows Z-order (HWND_TOPMOST), or by setting it to the bottom of the Z-order (HWND_BOTTOM), which by the way doesn’t mean that it will disappear immediately.

The position is saved automatically
Another message the thread’s window procedure handles is WM_EXITSIZEMOVE. This saves the (new) position of the ‘DebugClass’ window in the registry. It saves the position as a binary value from a RECT structure. It is saved under the a sub key name of ‘DebPos’ in ‘HKEY_CURRENT_USER/Software/GFA/Basic’. When this key doesn’t exist, it is created. When your customers application uses the debug window, the position will be saved in this registry key of your customers PC. Also note that your customer has the ‘Always on Top’ option available. This setting isn’t stored in the registry. (BTW the window position isn’t saved when the output window is in a minimized or maximized state.)

Give it an owner
I find the debug window - unowned toplevel - completely living on its own quite annoying. I think it should be owned by the main window (and thread) of the application that is using it. In case of GFABASIC this should be the Gfa_hWnd window, in case of a customer application, your main windows handle.

~SetWindowLong(Debug.hWnd, GWL_HWNDPARENT, Gfa_hWnd)
Assert GetWindow(Debug.hWnd, GW_OWNER) == Gfa_hWnd

As an example I added the Assert line. I was a little unsure what exactly setting GWL_HWNDPARENT would do and tested the result for what I expected it to do. Anyway, giving it an owner removes the Debug window from the taskbar and makes it behave like its owner. When the owner (Gfa_hWnd) is minimized, the debug output window is minimized. When the owner is (de-)activated the output window is de-activated.

Give it a different font
The edit control is the one and only child window of the debug output window. It has ID number 1 and its window handle is obtained using:

hEditCtrl = DlgItem(Debug.hWnd, 1)

Since it uses a non mono space font you might want to create your own font using API functions and then assign it to the edit control.

SendMessage hEditCtrl, WM_SETFONT, hFont, MakeWParam(1,0)


20 July 2013

What’s that Google+ Button Besides the Articles?

If you’ve been reading GFA-BASIC 32 articles for any length of time, you might have seen the “Recommend this on Google” button… I’m not a fan of plugging in every different crazy social network and putting widgets and buttons all over the blog.

So why do the Google+ button? Because Google uses these scores when they do their search rankings, and GFA-BASIC can use all the help it can get to keep these articles ranking well in Google.

So the next time you click that button, know that the community is thankful for your help!

25 June 2013

What to do with an OLE_COLOR?

An OCX/ActiveX control color property can be assigned any valid Win32 color reference. However, the OCX/COM libraries provide a special data type for color properties, the OLE_COLOR data type. This new type was invented to give VB-like programs an opportunity to differentiate between a normal Win32 color reference and system colors. These programs could then present a special color-selection dialog box that allowed the selection of system colors. The snapshot of the GB32 Ole-color selection is shown below.


RGB colors are of type COLORREF
Like an RGB-color value, an OLE_COLOR data type is internally represented as a 32-bit long integer. An RGB-color is referred to as a COLORREF value and is used with GDI device context functions. A COLORREF is simply defined as a 32-bit value used to specify an red, green, and blue components of a color requiring only 3 bytes. When specifying an explicit RGB color, the COLORREF value has the following hexadecimal form.


The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF.
To create a COLORREF color value, you can use the GB32 RGB() function. To extract the individual values for the red, green, and blue components of a color value, use the GetRValue, GetGValue, and GetBValue functions, respectively. For performance reasons these GFA-BASIC 32 functions are directly translated to assembly code; they are not implemented as function calls.

The OLE_COLOR type
When a COM object property (most often .ForeColor and .BackColor only) requires an OLE_COLOR color, you can either pass an RGB  value (COLORREF) or a COM specific formatted system color index value. A COM specific format has it’s high-byte set 0x80. An OLE_COLOR can have two formats only:

  • 0x00bbggrr (COLORREF value)
  • 0x800000xx, where xx is the index used by GetSysColor().

The object doesn’t do much with the OLE_COLOR value, it is more a kind of a storage type. For instance, you cannot pass an OLE_COLOR to a GDI device context handle. GDI doesn’t know what to do with a COM formatted system index color (0x800000xx). The OLE_COLOR value is simply saved in the private data of the COM object and remains unchanged until the application explicitly changes the value again. This way, the Get-color-property variant of the Put-color-property will return exactly the same value as was first put in.

How the OLE_COLOR is used
Since the format of the OLE_COLOR data type isn’t known to Win32 drawing functions, they must be converted to RGB colors first. Usually, the OLE_COLOR is converted on a just-in-time basis. Just before a painting operation is performed the OLE_COLOR (32-bit long integer) is tested for a high-byte value of 0x80. When the high-byte is indeed 0x80, the low-byte value is used as a parameter to the GetSysColor() API function, which in turn returns the RGB color value of the specified display element. See the code below.

Aside: Identifying display elements
Display elements are the parts of a window and the display that appear on the system display screen. These elements are identified using the API COLOR_* constants, like COLOR_BTNFACE, COLOR_WINDOW, etc. These API constants may also be used in the GFA-BASIC 32 function SysCol(idx), which is slightly easier to use and a bit faster due to caching.

Dim rgb% = SysCol(COLOR_WINDOW)

GFA-BASIC 32 also defines a set of OLE_COLOR constants to identify the system display elements. These constants are very much like the Windows API COLOR_* constants. However, instead starting their names with ‘COLOR_’ they start with ‘col’, like colBtnFace and colWindow. These GB32 OLE_COLOR constants have the format of 0x800000xx, where xx is the index for the display element. See the code below.

Convert an OLE_COLOR
When you want to use an OLE_COLOR value, make sure to convert the OLE_COLOR to a COLORREF (RGB) value first. This is the only color format Win32 understands. In GB32 you get hold of an OLE_COLOR when you use one the col* constants or retrieve a color from one of the Ocx-color properties. For instance, when you want to use the same color as the form’s background, you might very well end up with an OLE_COLOR with the high-byte set to 0x80.

Now, there are two possible ways to convert an OLE_COLOR to a COLORREF value.

1. Manually, in your code. For example this converts to an RGB-value:

Trace Hex(SysCol(colBtnFace))   ' =0 (SysCol: what is a colBtnFace?)
Trace Hex(colBtnFace)           ' =8000000F (an OLE_COLOR)
Trace Hex(OleToRGB(colBtnFace)) ' =F0F0F0 (the RGB value)
Trace Hex(OleToRGB(0x667788))   ' =667788 (no conversion)

Function OleToRGB(olecolor As Long) As Long Naked
  If (olecolor And 0xFF000000) == 0x80000000
    Return SysCol(olecolor And 0xFF)  ' LoByte
    Return olecolor                   ' RGB!

2. Use the system OLE function OleTranslateColor()

Declare Function OleTranslateColor Lib "oleaut32.dll" ( _
  ByVal OleColor As Long, _
  ByVal hPal As Handle, _
  ByRef ColorRef As Long) As Long

Dim rgb As Long Long

If OleTranslateColor(colBtnFace, Null, rgb) == S_OK Then _ Trace Hex(rgb)

The second option using OleTranlateColor() might be preferable because it can also return other GDI color formats, like a palette-index value. In addition in case of an error, it let you investigate the type of the error. See the SDK for more info.

More flexibility
You can use OLE_COLOR types with the GB32 graphic commands, though. All drawing statements, font statements, and color statements accept an OLE_COLOR type. GB32 converts the OLE_COLOR to a COLORREF before it invokes the corresponding GDI function.

Another nice page on GB32

Sometimes I scan the internet for GFA-BASIC 32 references. Recently I stumbled upon this site http://basic.mindteq.com/index.php?i=81 with a comment from Bruce Bell. He wrote a very nice summary of the GFA-BASIC 32 essentials. Chapeau!

23 June 2013

The Align Property of Command, Checkbox, and Option

The Align property of the Ocx controls Command, Checkbox and Option differ from other Ocx controls. The documentation for Align says that it indicates how an Ocx control is placed inside its parent or owner Ocx control, also called docking. Several predefined constants (basNoAlign (0), basTop (1), basBottom (2), basLeft (3), and basRight (4))  are provided to help using the correct docking value with Align.

The buttons are different
In GFA-BASIC32 the Windows BUTTON class controls (push)button, checkbox, and radio-button are implemented as Ocx Command, Ocx Checkbox, and Ocx Option, respectively. The position of the contents of the BUTTON control can be changed by applying a predefined BUTTON-style alignment value. These are defined in the winuser.h SDK include file:

#define BS_LEFT             0x00000100
#define BS_RIGHT            0x00000200
#define BS_CENTER           0x00000300
#define BS_TOP              0x00000400
#define BS_BOTTOM           0x00000800
#define BS_VCENTER          0x00000C00

These values can be applied using API functions or using the WinStyle property of the Ocx controls. In addition, these style bits can be set using the Align property of the BUTTON class Ocx controls (Command, Checkbox, and Option). However, the values that you can assign to Align are different than the values used with the docking purpose of Align. The documentation lacks proper explanation of using the Align property with buttons. (At least in the English help file.)So let me fill the gap.
The position of the contents of the BUTTON controls can be set using a value between 0 and 10, but not 3 and 7. There meaning - as described by the official GB32 documentation -and the corresponding button styles are listed below.

Value Position BUTTON Style Value
0 Center Normal H/V centered 0x00000000
1 Left BS_LEFT (vertical centered) 0x00000100
2 Right BS_RIGHT (vertical centered) 0x00000200
3 no meaning* BS_CENTER 0x00000300
4 Top BS_TOP 0x00000400
5 TopLeft BS_TOP | BS_LEFT 0x00000400 | 0x00000100
6 TopRight BS_TOP | BS_RIGHT 0x00000400 | 0x00000200
7 no meaning* BS_TOP | BS_CENTER 0x00000400 | 0x00000300
8 Bottom BS_BOTTOM 0x00000800
9 BottomLeft BS_BOTTOM | BS_LEFT 0x00000800 | 0x00000100
10 BottomRight BS_BOTTOM | BS_RIGHT 0x00000800 | 0x00000200

When one of the position values from the first column is passed to the Align property the value is shifted left 8 bits and then sent to the BUTTON control using

SendMessage(ocx.hWnd, BM_SETSTYLE, position, 1)
* The no meaning values 3 and 7 can be used in code, not in the Form Editor. When used in code, the internal GB32 function that implements Align will accept any value between 0 and 15! It simply shifts the value 8 bits left and sends it to the BUTTON control.

So, the value of the Align property is used to position the contents of a BUTTON control Ocx. The value is converted to a BS_* constant value as defined in the SDK and passed to the BUTTON control. In this particular case the Align property has a different meaning. Perhaps, it should be named ‘Alignment’ as with the Label Ocx controls.

19 May 2013

Mailinglist Is Back!

From Juergen, the man who provides the GFA-BASIC mailing list on his private server for the past 10-15(?) years:

Hi folks, my domain @liebenstein.de was for a time not available, because the domain was put mistakenly on a black list and out of name server listings. With that also the mailing list didn't work of course. Please excuse this, the list is now
available again.

Thanks, Juergen!

30 April 2013

GFABASIC Mailing-list gone?

Many of us now receive this notification since the 4th of April.

This page can't be displayed
  • Make sure the web address http://gfa-basic.liebenstein.de is correct.
  • Look for the page with your search engine.
  • Refresh the page in a few minutes.

The moderator Juergen, cannot be reached by his GB mailing list's e-mail address. Either he doesn't know the list in reachable or he unplugged it.
Questions can be send to this blog's e-mail address or at my personal address. I will make them public and when the mailing list remains off line I will start my own list.

07 April 2013

Favorite: On GoSub/GoTo/Call

One of my favorite programming constructs in GFA-BASIC is, and always has always been, the On value GoXxx statements. Although, I must admit, there was a time I doubt the usefulness and legality of this command, because C/C++ doesn’t offer such a branch instruction. At those times I was under the impression that it was a typical BASIC overkill command. However, it is definitely not, on the contrary! These statements let GFA-BASIC produce optimized branching code through the use of jump tables. C/C++ compilers can do this only when their ‘optimize to fast code’ - switch is set. Since C/C++ doesn’t support jump tables as a language construct, these compilers crunch together a switch/case block and try to turn it in a jump table just like GFA-BASIC does by default. These are the statements that produce highly optimized branching code without setting a compiler option.

On n GoSub label1, label2, …
On n GoTo label1, label2, …
On n Call Proc1, Proc2, …

My most favorite version is On GoSub. This allows for executing local subroutines labeled by a Label: and ended with a Return statement. This version is not compatible to C/C++, these compilers produce code compatible to GFA-BASIC’s On GoTo.

Not in an Editor Extension
As I mostly program editor extensions, I was surprised to got in problems with these branch statements. GFA-BASIC, like Visual C++, creates a jump table at the end of a function/procedure. However GFA-BASIC hard-wires the address of the jump table, with the presumption that the code starts at $400000 (hInstance). With dynamically loaded GLLs, that place was reserved for the IDE executable image (that is where the code is loaded). When the GLL reaches the execution of the On GoSub code it reads the execution address of the labels from the IDE’s code text section. To the GLL this code contains rubbish. When the GLL is loaded not all the addresses in the GLL code aren’t updated correctly.

As my goal is to create code as efficient as possible, I am a bit disappointed and maybe I will try to fix the GLL-loader.

07 February 2013

SetFont 0 or Null?

In 2002 Peter Harder wrote:  "SetFont 0" oder "SetFont ungueltiges_handle%" sorgen im Gegensatz zu GFA16 bei GB32 für einen Programmabbruch. Tückisch vor allem  dann, wenn dieses Problem beim Umschreiben eines GFA16-Programms ' erst beim Kunden auffällt; ein Hinweis in der Onlinehilfe auf  diesen Unterschied fehlt.

What is this about SetFont?
In previous versions of GB the statement SetFont 0  was often used to select a default stock object font in the current active device context. Peter’s remark suggests that this functionality is missing from GFA-BASIC 32. However, it isn’t actually missing, but the data type of the argument is a Variant, rather then an integer. The 0 value is automatically converted to a Numeric Variant (data subtype = basInt) with value 0. This means: 0 is a valid numeric value and is handled as if the font-handle with value 0 is passed to SetFont.

It throws an error
The SetFont library routine checks for a numeric value in the Variant and uses that value to select a stock object. However, the valid value 0 references the WHITE_BRUSH stock object and not a font. SetFont stops and throws an error. ( The error “Illegal Function call”, which, of course, should have been “Invalid Parameter”.)

Use Null instead
To have SetFont select a stock object, to be precise, the DEFAULT_GUI_FONT, the Variant argument of SetFont must be set to the VT_NULL variant subtype. This is done by using the Null constant.

SetFont Null

The Null keyword is used with a Variant to indicate that it intentionally contains no valid data.

But what if you have a variable that is holding a font handle? Well, in case the font handle is 0, you would want to pass a VT_NULL variant subtype, so you must convert it to Null. You could use the explicit Null constant as above, but you can also use an undocumented function Null(value), which is replaced by a simple Null.

Global font%
If font%==
SetFont Null(font%

14 January 2013

Using Fonts the old-way

The old-style font commands from GFA-BASIC for Windows 16 can still be used in GB32. However before using them you should be aware of an essential difference between GB32 and GB16. Beside this you should also know what the consequences are when applying the GB16 font commands.

The GB LOGFONT structure
In GB16 the font commands applies to one, and only one, internally maintained, global LOGFONT structure (user defined type). In GB32 there are multiple LOGFONT structures and none of them is a global variable. The LOGFONT structure is now part of a Form object and the font commands now work on the LOGFONT of the current active Form (Me)

The LOGFONT type is defined in wingdi.inc.g32 located in the Include directory of your GB32 installation.

' Logical Font (wingdi.h)
Global Const LF_FACESIZE = 32
Global Const LF_FULLFACESIZE = 64

  lfHeight As Long
  lfWidth As Long
  lfEscapement As Long
  lfOrientation As Long
  lfWeight As Long
  lfItalic As Byte
  lfUnderline As Byte
  lfStrikeOut As Byte
  lfCharSet As Byte
  lfOutPrecision As Byte
  lfClipPrecision As Byte
  lfQuality As Byte
  lfPitchAndFamily As Byte
  lfFaceName(LF_FACESIZE) As Byte
End Type

Regardless of the GB version, the members of the current LOGFONT variable are set and read using the same set of commands. In GB16 they are applied to the one global variable, but in GB32 they still set and read the LOGFONT members from the current active Form (Me).

GB-Command Description
FONT member value sets a value to a member
RFONT member variable reads a member value into a variable
variable$ = _Font$ copies all logfont-members into a string
_Font$ = variable$ sets all logfont-members from a string
Dlg Font sets all logfont members from a users font selection
Font To hfnt Creates a logical font from logfont
FreeFont hfnt Deletes a logical font
GetFont hfnt Obtains loglont values from a logical font
SetFont hfnt Selects the logical font into the window's DC

After filling the LOGFONT members (using Font name, _Font$, or Dlg Font) the Font To hfnt invokes the GDI function CreateFontIndirect() which returns a Windows handle to the font created. This functions allocates memory whose memory handle is returned in the hfnt variable (32-bits). This font memory must be released by the application explicitly using FreeFont hfnt.
The GDI fontmapper creates the font that best matches the values in the LOGFONT structure. However, they might be different from what was requested. To obtain the attributes of the GDI created font, the application would use GetFont hfnt. This reloads the LOGFONT values from the actual font handle.

What about SetFont?
In GB32 this commands invokes a series of complex procedures. In GB16 it was as simple as selecting the logical GDI font handle into the current device context. In addition, in GB16 the current device context could be manipulated using SetDC, which is obsolete in the 32-bits version. Of course, eventually, GB32 will select a font handle into a device context like in GB16, but GB32 goes the COM way. As such the GB command SetFont hfnt creates a hidden Font object and performs a Set Me.Font = hiddenFont (from hfnt).

Finally, any font the application created the old way using Font To must(!) be released explicitly when it is no longer in use. Meaning after that some other font has been set. (Either using SetFont or using the Form's property Font.)

11 January 2013

Use the Explorer Preview Pane

This time I want to share a tip with you. I'm a big fan of the Explorer Preview Pane a facility that can show the contents if files next to the files in a separate pane. It allows and helps me to quickly scan C/C++ (header) files, readme-text files, and other plain text files. Most often it helps to scan through MSWord en PDF files as well. I use it for GFA-BASIC 32 files as well.
Preview GFA-BASIC 32 files
GB32 files are plain text files as well. So it would only be logical (as Spock would say) to view them in the preview pane as well. It is not only logical but possible as well. You can assign the '.g32' extension to the default Text Viewer of Windows Explorer by using a registry hack. However, this is not only cumbersome, but a bit complex as well see http://blogs.msdn.com/b/toub/archive/2006/12/14/preview-handler-association-editor.aspx. In the article Stephen Taub, author of the program, describes the Preview Handler Association Editor tool.
This utility helps in assigning all registered file-extensions to a preview handler. Note that since Windows Vista the GFA-BASIC 32 file extension .g32 can only registered when GB32 is started in Administrator Mode. Then go to Properties and click the button to register the g32 and lg32 file extensions.
Changing the font
To change the standard font of the preview pane isn't difficult, because the pane always uses the current Notepad font. By changing the default font of Notepad you change the font of preview pane when using the Windows TXT Previewer.
Procedure: Launch Notepad and select Format/Font... from the menu bar. Change the font and close Notepad. Now text files should be rendered in the font you just selected.

04 January 2013

Memory Leak on Image Ocx

At the end of 2012 Peter Heinzig posted a sample showing GFA-BASIC 32 memory leaks with the Form and Image Ocx. In Memory leak with Form.Picture I focused on the Form object and a remedy against the memory leak. In the meantime I investigated the Image Ocx and can confirm a memory leak when the Ocx control is destroyed. Just like the Form Object the Image Ocx doesn't release it's Picture object. The remedy is actually the same. In the parent Form Ocx _Destroy sub event add a command to release the Picture property of the image control.

The solutions presented here are applicable on all versions of GFA-BASIC 32. However I hope to build an update of the runtime as soon as possible. I hope these are the only memory leaks, but it takes time to verify these are the only Picture objects that aren't released after a program has been closed.