Clarion projects – Window structures in the RTL

The following is excerpted from an MS KB article:
The Microsoft Platform Software Development Kit (SDK) documentation for the CreateMDIWindow function says that “(u)sing the CreateMDIWindow function is similar to sending the WM_MDICREATE message to an MDI client window, except that the function can create an MDI child window in a different thread, while the message cannot.”

Applications that use the CreateMDIWindow function to create a multiple-document interface (MDI) child window on a thread other than the thread that owns the MDICLIENT window may experience problems with the way that MDI manages the client windows. The following problems may occur:

• – The list of windows on the frame’s window menu may not be complete.
• – The management of the MDICLIENT scroll bars may not be consistent when you move or size MDI child windows.
• – The keyboard cannot be used to move between the menus in the frame window and an MDI child window.

RESOLUTION To resolve this problem, applications should not call the CreateMDIWindow function to create MDI child windows on a thread other than the thread that owns the frame window and the MDICLIENT window (emphasis added).
***

So there you have it. MS doesn’t want or support multi-threaded MDI programs at all.  In fact the .Net runtime displays an error message if you even try to open a window on any but the programs main thread. We have spent literally hundreds of man-hours trying to make MS MDI behave in a multi-threaded program. We know the real life implementation of the MDI API is not thread safe, and never will be. To workaround this deficit we have encumbered the RTL with synchronization code to try to mitigate the OS level problems. I say encumbered; (restrict or burden (someone or something) in such a way that free action or movement is difficult) because that best describes the situation. The extra code we were forced to add restricts our ability to add new functionality, without risking breaking the MDI synchronization sequence we spent so much time on making it work.  So to move forward we have a project underway that will allow us to remove the burden of the synchronization objects, solve all of the above listed MDI issues, and best of all, allow us to add new functionality with 100% backward compatibility.

At next weeks DevCon I’ll be going into the details of what we are doing to solve this issue once and for all, and describing the exciting new abilities that it will bring to Clarion programs.

Clarion projects – Report Engine

The Clarion Report engine ( the engine in the RTL) has been evolving since it was first implemented in the original Clarion for Windows back in the W95/98 days. Its uses Windows metafiles to generate Reports. Metafiles are created in memory and are written to disk files. The RTL also uses metafiles for direct drawing as in ARC() or PIE() both REPORTs and WINDOWs. A metafile is a simple way to store drawing operations but there are several limitations:

Windows metafiles do not support all GDI functions, for example, images with semi-transparent parts can’t be stored in Windows metafiles. Reports are actually sequences of bands. Bands consist of controls and they can be nested. Multiple drawing operations can be required to draw controls. For example, multiple lines and multiple strings must be drawn for LIST controls. Reports are actually represented internally with a tree structure, and metafiles with their linear organization are not really an adequate way to represent them. The BLANK statement with parameters makes it necessary for the RTL to insert some additional records right in the middle of the metafile. The RTL must also carefully track images, pens and fonts used in metafiles to provide a correct representation of the report, and to avoid leaking of resources.

At the upcoming DevCon in Orlando I’ll be talking about (the details) of how we plan to solve these types of issues, and at the same time bring brand new capabilities to your reports. And as we always strive to do – maintain 100% backward compatibility.

Clarion Projects – Touch support in the RTL

Touch input affects all Windows (all objects with HWND handles), and all controls. A generalized processing of touch gestures and mouse input requires changes in the hierarchy of classes within the RTL that deal with user interactions. By generalized I mean the ACCEPT loop must recognize and handle all possible “gestures”, and then it needs to decode sequences of WM_POINTER* messages to matching gestures and send them back to the your program in a way that makes it easy to respond to. And further, indirectly Touch support affects some areas that are not related to input at all, for example setting and getting properties.

The RTL also needs to expect that touch/pointer messages can be sent to different windows depending upon where the touch is done, and to windows running in different threads as well.  Clarion programs are typically very thread-intensive, unlike the typical MS VC/VB/C# programs which in terms of use of threads, are diametrically the opposite (the UI is almost always single-threaded).

In other words the implementation isn’t a project for a rainy weekend, instead its a complex melding of current code to recognize
user input, with a brand new set of requirements for touch gestures.

A brief description of some of the functionality being worked on:
– scrolling of LIST control
– Zoom in/out
– touch to press button, toggle checkbox, select radio option
– touch to give focus to other controls
– and others that we are still imagining