19 January 2013

Runtime Update 1181

The update Build 1180 from last week caused some problems due to a new bug that manifested itself as a result of the fixes. The problem was the Form Close method. It invoked a function that was called again when the window was actually destroyed. At that point the contents of the variables were undefined and the Close method halted with an Access Violation error.

Download: GFAWin23.Ocx Runtime

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

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

13 January 2013

Removal of update Build 1180

Today, 13 January 2013, I temporarly have removed Ocx1180. The runtime OCX Build1180 (from 06-01-2013) because of reported runtime errors. This Build should have fixed memory leaks with Form.Picture and Image.Picture.

Hopefully, the update can be restored soon.

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

07 January 2013

Download Update Ocx Build 1180

The memory leak bugs described in Memory Leak with Form.Picture Object en Memory leak with Image Ocx are fixed in the latest runtime version. The update of the file GfaWin23.Ocx has build number 1180. It can be download from the download page.

Go To Download Page

Note Do not forget to replace all occurrences of this file. Often it is placed in a program's directory or in a Windows system directory!

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.