Parallel Parking and Other eDeveloper V10 Tricks

The eDeveloper enterprise server supports parallel execution of tasks or multithreading. Whether your tasks are truly executed in parallel or are conducted in pseudo-parallel mode through a technique called time slicing is dependent on your hardware and operating system. With traditional programming tools, the programmer must carefully design the program in such a way that all the threads can run at the same time without interfering with each other. With eDeveloper, multiple contexts are maintained automatically and controlling contexts is simplified tremendously compared to unnecessarily complex 4GL and 3GL development systems.

And the good news, no the great news, is that multiple document interface (MDI) and single document interface support is now built-in to eDeveloper, further simplifying development of applications that meet the needs and demands of your users.

In the list of 51 reasons to upgrade to eDeveloper V10, reasons 42 through 46 are dedicated to parallel execution, i.e., multithreading. Let's take a closer look at each claim to better understand what's behind it.


42. Concurrent Task Execution – Provide a greater application productivity level by enabling the end-user to run several processes - online and batch - simultaneously.

In eDeveloper v9.x, multithreading was available for background processing only. Now with eDeveloper V10, background enterprise servers and Online programs are multi-threaded. This gives you the ability to have parallel task execution in your projects for both batch and online tasks.

Each thread accesses a different Runtime context, and does not interact with other threads, in other words, it is stateless.

To work with multiple threads in Online programs, eDeveloper V10 provides you with powerful new Multiple Document Interface (MDI) and Single Document Interface (SDI) functionality.


43. Single Instance – Easily control concurrently running tasks to keep a single instance for proper implementation of console screens, palettes, and property sheets.

When you are using parallel tasks, and you call a program again, a new instance of the program opens. To better illustrate what we mean, consider what happens with a well-known application like Internet Explorer. The first time you open Internet Explorer, one instance of it opens to your default home page. When that instance is open and you open Internet Explorer again, a second instance opens to the default home page regardless of the context, i.e., the current URL of the already open browser window. However, sometimes you want the same context to open, such as when you use the "New Window" option in Internet Explorer and you get a second window with the same context as the previous window. A third option is that you do not want multiple windows and contexts. You want the new instance with its new URL to open in the already open window. Internet Explorer allows the user or the developer to control this kind of functionality.

eDeveloper V10 now supports both multiple document interfaces and single document interfaces and gives you as the developer, control over the way contexts are handled. In those situations where you want the second call to return to the original instance, this is what eDeveloper's Single Instance task property does. When you select this property, when a program is called for a second time, the focus will be set on the already running instance. However, there will be no initialization steps (such as preparing the data view).

44. Event Posting – Enable full interaction between all concurrent processes using the inter-context event posting mechanism.

Most of the time, you will probably want instances to execute independently, but there are some events that may require you to enable events to be sent between contexts. Using eDeveloper V10's event posting functionality is accomplished via the Destination Context Name property of the Raise Event operation. The mechanism allows for synchronous and asynchronous events. If a synchronous event was raised, the context waits until the receiving handler ends. I like the fact that eDeveloper V10 gives the developer all of these options and doesn't restrict the developer to stateless contexts without interaction.

45. Single & Multiple Document Interface – You now have the freedom to choose the layout by which your parallel tasks will be presented. You can have a parallel task be displayed as yet another MDI child window or an independent SDI window.

This is another new eDeveloper V10 feature that standing completely on its own will justify the upgrade in the minds of many developers. eDeveloper lets you define a Multiple Document Interface (MDI) as well as a Single Document Interface (SDI).

In the most basic of terms: the MDI and SDI functionality allows an application to open and concurrently run several tasks. That is, it enables a program to be opened concurrently without the need to open a new instance of eDeveloper.
The eDeveloper engine can maintain multiple concurrent instances, executing programs within the same application and within the same eDeveloper instance.
In eDeveloper, concurrent execution is implemented using contexts. When a program is run concurrently and a new context is opened, the new context will have its own Main Program. This Main Program and context are independent of the other contexts running under this process. Read up on the MDI and start using it, your users will applaud.

46. Window Focus Management – Using a simple set of functions and events eDeveloper gives you a full control over the focus management of all your windows. Easily handle lost-focus events and easily instruct a window to get focus.

The default behavior for contect management is pretty much as you would expect: When focusing on a window in a different context, eDeveloper will not lose track of the control in the current context. In this fashion, when focus is passed back to this original window, it will pass back to the same control. Similarly, if there is a window that is not in focus, and a dialog box appears, such as a Verify operation or the window's own form with a Window Type property of Modal, the focus will pass to the dialog box. If a different context opens a window, the focus will pass to that window. Using the expression editor, you can utlilize the SetWindowFocus function to determine the particular window in the Window list that will be in focus. During runtime, if the window does not exist (the name does not exist or the name is blank or Null), focus will remain on the current window and the function will return False.

So all in all, parallel execution is another home run for eDeveloper V10, if you will forgive the baseball metaphor. The multi-threaded architecture of eDeveloper can now be enjoyed in both online and batch mode. Just in time, I think, as duo core and quad core processors are becoming commonplace on client desktops. You'd better get ready now as the world of parallel processing has entered the mind of the everyday user and they will demand the functionality that eDeveloper V10 delivers.