|
|||||
| IN THIS ISSUE | |||||
| New in Synergy/DE 9.3! Binary Prototypes Speed up compiles and reduce dependencies By James Sahaj, Project Manager for Synergy .NET compiler Implementing Interoperability Between Embedded .NET WinForms and Your Existing Synergy/DE UI Toolkit Logic By Richard Morris, Senior Consultant, Synergy/DE Professional Services Group Did You Receive Your 2010 Synergex Calendar? If not, let us know! Synergy/DE Tech Tip Consuming keyboard input in a .NET form in a UI Toolkit application Quiz See if you can answer this question! Platform News Read a selection of recent articles Synergex Holiday Reminder We will be closed on Monday, January 18, 2010, in observation of Martin Luther King Day |
|||||
Speed up compiles and reduce dependencies
By James Sahaj, Project Manager for Synergy .NET compiler
In version 9 of the Synergy compiler, we introduced the concept of prototyping. Prototyping enables a developer to check calls against definitions of routines or classes. We have heard from many of our users that this feature alone found many bugs they didn’t even know they had in their code, catching bugs at compile time that may never otherwise have been discovered.
Since that release, we’ve made this feature more flexible. The original v9 prototype files, with a .dbh extension, contain code that looks just like the source code, minus the implementation. Because these files are text based, the compiler needs to parse the files in order to import the prototypes, which can make an application with a lot of prototypes compile more slowly and cause the compiler to use more memory. In addition, the types used in those prototypes must be fully resolved, causing additional dependencies between prototype files. This forces a developer to import potentially far more namespaces than are being used in the application.
> continue
Implementing Interoperability Between Embedded .NET WinForms and your Existing Synergy/DE UI Toolkit Logic
By Richard Morris, Senior Consultant, Synergy/DE Professional Services Group
When the Synergy .NET assembly API and the UI Toolkit .NET routines were released in Synergy/DE 9.1.5 (July 2008), developers were given the ability to harness the powerful controls and classes within the .NET Framework. With these features, you can enhance the presentation layer of your application by replacing your UI Toolkit input windows with Windows Forms, which offer a greater array of input controls than standard input windows.
This article describes the first steps towards replacing your UI Toolkit input windows with Windows Forms. We’ll use this past year’s SPC demo application, ChronoTrack, to illustrate how to start migrating an existing UI Toolkit application to .NET. ChronoTrack is a UI Toolkit application whose user interface has been enhanced using .NET forms. It was created by the Synergex Professional Services Group (PSG) to demonstrate the capabilities of the latest released versions of Synergy/DE, and it uses many of the modern tools and technologies now available to the Synergy developer.
> continue
Did You Receive Your 2010 Synergex Calendar?
If not, let us know!
If you did not receive your Synergex 2010 calendar, or would like additional complimentary copies, please email us at synergy@synergex.com. Include your address and the quantity you’d like, and we’ll send them your way.
Synergy/DE Tech Tip
Consuming keyboard input in a .NET form in a UI Toolkit application
If you use the UI Toolkit .NET routines (DOTNET_TKADDCTL, etc.) to embed a WinForm or WPF control in a UI Toolkit window, UI Toolkit generally handles keyboard input as you would expect. There are, however, some edge cases that can cause confusion. For example, if you have a custom control that’s designed to consume the ESCAPE key, the control probably won’t be able to consume it because the form will consume it instead. Fortunately, there are ways to redirect keyboard input to work around these edge cases. Unlike the ActiveX API’s AX_WANTSKEY routine, however, that redirection isn’t controlled by the UI Toolkit application. Instead, the .NET control or its form dictates what processes a keystroke.
Generally, all keystrokes except accelerators (keystrokes that can be mapped to menu entries) are sent to the .NET component as input. TAB and SHIFT+TAB, however, are special cases if the UI Toolkit window that contains the .NET form is in a composite window. If this is the case, and the first control within the .NET component has focus when SHIFT+TAB is pressed, Toolkit passes that keyboard input out to the Toolkit container. The same is true of TAB if it’s pressed on the last control in the component.
Apart from this special handling of TAB and SHIFT+TAB for composite windows, whenever a keystroke occurs during DOTNET_TKINPUT processing, UI Toolkit calls the PreProcessMessage method for the .NET form. (See http://msdn.microsoft.com/en-us/library/system.windows.forms.control.preprocessmessage.aspx.) If that method returns true, UI Toolkit does not attempt to translate the keystroke as an accelerator, so it is dispatched to the form as a normal keystroke. This makes keystrokes such as TAB, SHIFT+TAB, and ESCAPE work as you would expect most of the time, because the standard behavior for a .NET form is to consume those keys.
Special Cases
If you have a custom control that’s designed to consume TAB, SHIFT+TAB, or ESCAPE (instead of letting the form use them for navigation between controls or as an accelerator), you can override the control’s ProcessCmdKey method and return true to indicate that the key was processed. (See http://msdn.microsoft.com/en-us/library/system.windows.forms.control.processcmdkey.aspx.) For example, the following is part of the source for a user control written in C# that handles each of these keys by setting the text of a label to indicate which key was pressed:
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
switch (keyData)
{
case Keys.Tab:
label1.Text = "tab";
return true;
case Keys.Tab|Keys.Shift:
label1.Text = "shift-tab";
return true;
case Keys.Escape:
label1.Text = "esc";
return true;
}
return base.ProcessCmdKey(ref msg, keyData);
}
Another way to override keystroke behavior is to override the control’s IsInputKey method (See http://msdn.microsoft.com/en-us/library/system.windows.forms.control.isinputkey.aspx.) Note, though, that this method is not invoked for form-level accelerators such as ESCAPE.
If you don’t have access to the code for the control, you can direct keyboard input by overriding the form’s PreProcessMessage method. Even if you’re using a pre-packaged form, you can always embed that form in a form of your own that overrides the keyboard input handling.
Quiz
Synergy/DE pros, see if you can answer this question!
How do you get the current Coordinated Universal Time (UTC)?
a. %datetime()
b. %datetime(%timezone())
c. %datetime() - %timezone()
d. ^d(%datetime()) - %timezone() * 60000000
Click here for the answer and explanation.
Platform News
35 Google Open-Source Projects that You Probably Don't Know
Google Chrome OS Goes Native (code)
Windows
Activate Windows 7's Hidden 'God Mode'
Russinovich: A Possible Cure for Exploitable Heap Corruption in Windows 7
Visual Studio Launch Delayed by 'A Few Weeks'
OpenVMS
OpenVMS Roadmap Updated
Linux
With Eye on Oracle and MySQL, Red Hat Invests in EnterpriseDB
Synergex Holiday Reminder
We will be closed on Monday, January 18, 2010, in observation of Martin Luther King Day. If you anticipate needing our assistance on this day, please contact us at synergy@synergex.com to make arrangements.