| X-Designer User's Guide |    
|
| X-Designer User's Guide |
|
| C H A P T E R 11 |
|
Designing for Microsoft Windows |
This chapter describes how you can use X-Designer to design applications to run under Microsoft Windows. X-Designer generates MFC (Microsoft Foundation Classes) code for your design which is then directly portable to Microsoft Windows. This chapter covers the following areas:
Chapter 12 provides step-by-step instructions for creating a Windows-compatible design and generating the MFC code for it. Following this tutorial would give you a detailed insight into the use of X-Designer for creating Windows applications.
This chapter makes certain assumptions about your knowledge of X-Designer. It is assumed that you understand structured code generation, as described in Structured Code Generation and that you are comfortable with the idea of generating C++ code. C++ Classes provides information on C++ in X-Designer.
You may wish to follow the tutorial in Chapter 9 to gain experience with the generation of C++ code.
The best way to develop an application which is to be ported to different platforms is to encapsulate the platform specific parts in some way so that the body of the application is isolated from the implementation details. X-Designer uses its C++ code structuring capabilities to generate a set of classes for the user interface that have the same public interface, but two different implementations. In X-Designer these implementations are known as flavors. There are three flavors of C++ code that can be generated:
When you generate code for Microsoft Windows using MFC, you are given the choice of:
For the first option above, X-Designer generates some MFC code to fetch widgets out of the dialog templates and to control the dialogs, thereby generating a complete application.
To generate dialogs as resource files, set the "Generate as Resources" toggle in the Code Options dialog.
If the "Generate as Resources" toggle is not set, plain MFC is generated for your design. By default, the toggle is set.
The full capabilities of X-Designer's C++ model can still be used for MFC applications. This means that you can use sub-classing and inheritance to add additional functionality. These techniques can be used, for example, to support cross platform versions of your user-defined widgets.
There are three methods of invoking X-Designer so that it is running in Microsoft Windows mode. Select the method which suits you best, bearing in mind that you may have to share your copy of X-Designer with other users who do not want to run X-Designer in Microsoft Windows mode.
Microsoft Windows mode can be specified by a resource in the file containing your X-Designer application resources:
XDesigner.windows: true
Microsoft Windows mode can also be specified by a command line switch when invoking X-Designer:
xdesigner -windows
The third method of invoking X-Designer in Microsoft Windows mode gives the appearance of a separate application which is always in Microsoft Windows mode. This method uses the application resource, described above.
1. Create a hard link to your X-Designer shell script in the $XDROOT/bin directory.
2. Give this file a name such as xdesignerwin.
3. Create a hard link to your X-Designer binary in the $XDROOT/lib directory. Use the same file name as in Step 2.
4. Add the windows flag to the .Xdefaults file in your home directory, using the name of your symbolic link, as follows:
xdesignerwin.windows: true
In this way, you can simply type
This will invoke X-Designer in Microsoft Windows mode. Other people can then continue to use X-Designer safe in the knowledge that the default will not be Microsoft Windows mode.
The X-Designer Window looks slightly different when in Microsoft Windows mode. The main differences are the addition of two items in the toolbar at the top (and in corresponding menus) and the fact that some of the widgets are not included in the widget palette. This second point is dealt with in Microsoft Windows Compliance. The first set of differences is described here.
There are two Microsoft Windows Compliant toggles--one on the toolbar and one in the Module menu. They both have the same function.
[ D ]
These toggles indicate whether or not the current design is Microsoft Windows compliant. If you read in a design created with a version of X-Designer not in Microsoft Windows mode or you cut and paste areas of a compliant hierarchy, it is possible to create structures which are not Microsoft Windows compliant.
In such a case a message is displayed informing you where the problem is and the two Microsoft Windows Compliant toggles are unset. The toolbar toggle displays a red cross when it is unset. Having made the appropriate changes to your design, pressing either of these toggles will check the compliance again. If your design is now Microsoft Windows compliant, the toolbar button will be set (the red cross will disappear). If not an error message will appear indicating the problem and the toggles will remain unset.
The flavor menu in the toolbar specifies which flavor of code you wish to generate: plain Motif, Motif XP or Microsoft Windows. This only applies to C++ code generation.
In addition to the compliance issues which prevent code from being generated for Microsoft Windows, there are many attributes of a design which have no effect in the Microsoft Windows implementation (for example the alignment of a label on a button), because the Microsoft Windows toolkit does not support the concept. X-Designer indicates this by means of the following:
If the variable name field of the selected widget is pink, this indicates that the widget will not map to any equivalent Microsoft Windows object. For instance, in Microsoft Windows a menubar is simply an attribute of a Dialog, there is no menubar object. Consequently X-Designer will show the variable name pink for menubar widgets.
X-Designer will also use this technique to indicate that some links will not be reproduced in the Microsoft Windows code. Links are discussed in more detail in Using Links.
Unfortunately for the user interface developer, the Motif and X toolkits bear little resemblance to the Microsoft Windows toolkit. Although the visual appearance is similar, the actual use of the toolkit is very different. This requires X-Designer to impose some restrictions on the developer before Microsoft Windows code can be generated for a design. X-Designer will impose these restrictions when it is in Microsoft Windows mode. When X-Designer is in Microsoft Windows mode it needs to permit the developer to work on designs which do not comply with these restrictions (so that an existing design can be read in for example). As a result X-Designer will check that a design is Microsoft Windows compliant. If a design is not Microsoft Windows compliant then C++ code can only be generated for the Motif flavor.
Widget tranformations are particularly useful when you need to fix compliance failures. See for a list of the permissable transformations.
This section details the restrictions imposed by X-Designer which ensure that Microsoft Windows compliant code can be generated. When in Microsoft Windows mode X-Designer will not allow you to create a design which violates these restrictions.
Because of the differences between Motif and Microsoft Windows in the way events are handled, some widgets cannot be made classes. In Microsoft Windows, events concerning certain widgets are always sent to the enclosing class. Other widgets must be classes in order to handle Microsoft Windows messages. Here is a list of these restrictions:
The first error you are likely to encounter on reading a non-compliant design is the fact that the Shell must be structured as a C++ class. This error is easy to fix and can be done automatically from the Compliance Failure dialog. See Compliance Failure for more details.
X-Designer does not support the Function or Data Structure options in a compliant design.
Structural errors can be considerably more complicated if you have a design which is well-structured, making good use of C++ classes and with callback methods scattered among the child widgets. The following example demonstrates how this problem may occur and how to overcome it.
When a widget is given a callback method, the method is declared in the enclosing class. In the following example, while using a version of X-Designer which was not in Microsoft Windows mode, the MenuBar, MBar_class, and the Shell were both declared classes and the button given a callback method:
[ D ]
The method is declared in MBar_class. If you then read the design into a version of X-Designer in Microsoft Windows mode, you will be presented with the following error message because MenuBars cannot be classes:
If you remove the class definition of the MenuBar (using the Core Resources dialog), you will then see the following error message:
Make sure that the method declarations are removed from the MenuBar and, in this case, added to the Shell by either pressing the "Declare all" button or selecting "active_button" in the list and pressing "Declare". You cannot add them to the Form because the Form, like the MenuBar, does not map to an object on Microsoft Windows.
Although X-Designer assists you in the above way, changing whether a widget is a class or not could have a major impact on your application. You will need to reconsider the structure of your application very carefully.
Menubars in Microsoft Windows are created by setting an attribute of the Dialog. This leads to two compliance restrictions:
The File Selection Box must be a child of a DialogShell. In Microsoft Windows file selection is provided by a pre-defined FileSelection Dialog. This dialog can only contain a single work area child, it cannot support a Menubar, nor additional buttons (not managed by the work area).
The following widgets have no comparable control in Microsoft Windows and so cannot be used in a design that is to be portable:
All but the last two buttons, however, can be emulated using the Dialog Template widget, which is supported as a Windows control.
The following widgets also have no comparable Microsoft Windows control. Any child widgets contained within them are mapped as standalone controls.
The Scale widget maps to a Microsoft Windows ScrollBar control which cannot support child controls. Therefore a Scale widget with children violates the Microsoft Windows compliance restrictions.
Because of the way messages are passed to an enclosing control, both Frame and RadioBox (if not the child of a Frame) have to be classes. However, as the child of a Shell cannot be a class, it follows that neither Frame nor RadioBox can be the immediate child of a Shell.
The second child of a Frame must be a Label widget--this is the title of the Frame. The Frame control in Microsoft Windows (actually a CButton in disguise) simply has a title attribute. There is no way to use another control as the title. The first child can be any widget.
A compliant design cannot contain a Paned Window which has Separator, MainWindow, OptionMenu, or MenuBar children. Neither may the children be definitions or instances.
The XmNlabelType resource cannot be explicitly set for a widget which is a component of a definition when it is instantiated in another design. If a Button does not have XmNlabelType set in a definition then when that definition is used XmNlabelType cannot be set to PIXMAP. This is because Microsoft Windows uses a different class (CBitmapButton instead of CButton) to implement a button with a bitmap on it. It is obviously not possible to change the class of a variable after it has been created, hence the restriction.
For the same reason it is not possible to have a CascadeButton in a definition which has no Pulldown menu and to then add the Pulldown in an instance.
You cannot make the child of a shell widget the root of a definition because you cannot make the child of a shell a C++ class, as explained in Structure Restrictions. To overcome this restriction, simply add a "dummy" container between the shell and the widget you wish to use as the root of your definition.
Slightly more subtly, it is not possible to have a widget with methods added to an instance which is not being sub-classed. For example, if you have an instance of a RowColumn definition, and the root widget (i.e. the RowColumn) does not have its structure set to class. When not in Microsoft Windows mode it is possible to add a button to the RowColumn instance and give it a method callback which is declared in an enclosing scope (say a Shell class). This is not possible in Microsoft Windows; the event has to be handled by the enclosing control (in this case the CWnd which represents the RowColumn).
The widgets in a definition must be named. This is a requirement for all C++ definitions, not just those destined for use under Microsoft Windows.
When you read in a design which was created by X-Designer while not in Microsoft Windows mode or you use cut and paste in such a way as to cause a design to become non-compliant, the Compliance Failure dialog appears showing you which widgets are causing the design to be non-compliant.
You can select the widgets in the scrolled list of non-compliant widgets. You may then press one of the following buttons:
This example shows how compliance failure is detected. In the hierarchy shown in FIGURE 11-7, the RowColumn widget rc_is_class has been made a class:
[ D ]
If you were to cut rc_is_class, clear the form and then paste (i.e. pasting rc_is_class as a child of shell), X-Designer would mark the design as non-compliant and display the Compliance Failure Dialog shown in FIGURE 11-8 indicating that the child of a shell may not be a class:
X-Designer allows you to continue with the operation but until you change the structure of rc_is_class, you will have a design which is not Microsoft Windows compliant. The Microsoft Windows compliant toggle in the toolbar displays a red cross to remind you.
In the Motif flavors links are pre-defined callbacks. In the Microsoft Windows flavor they are implemented as simple global functions which are called by a button's message handler. There are, however, some restrictions on how links can be used on Microsoft Windows. These restrictions only affect whether code is generated for a link, they do not affect the design's compliance.
If the widget selected as the destination of a link is not mapped to an object on Microsoft Windows, the Add button in the Edit Links dialog is pink. The link can still be added and will be effective on Motif but it will not be generated into the Microsoft Windows code. To indicate this, the widget in the list of links is pink. See Mapping Motif Widgets to Microsoft Windows for more information on which widgets are mapped to Microsoft Windows objects.
When adding a link where the destination widget is a PushButton in a Menu, the type of link is restricted to enable and disable. You cannot show, hide, manage or unmanage a Menu Button on Microsoft Windows.
FileSelectionBox is implemented on Microsoft Windows as a CFileDialog, a modal dialog which is shown by calling the DoModal method. This method does not return until the FileSelection is complete or cancelled. On Microsoft Windows, therefore, only the show link is supported. For both MFC and Motif XP flavors the code is structured so that the DoModal method does not return until the selection is complete or cancelled.
The Motif manager widgets have no equivalents on Microsoft Windows. Widgets such as Forms and RowColumns do not exist on Microsoft Windows. If you have one of these in your design which is not a class, it is ignored in the generated code. If it is a class, X-Designer generates a Canvas in its place.
If you are generating dialog templates from your design, most manager widgets are ignored because dialog templates tend to be flat. They do not use the containment hierarchy that is common on Motif. Your design, therefore, is flattened out in the template files. Widgets are taken out of sub-containers and made children of the dialog. This also enables system resources to be used throughout the design.
If you choose to generate your design into Windows resource files (or dialog templates) along with the main application code, you will be able to make adjustments to the layout using your Microsoft Windows IDE (Integrated Development Environment). These changes cannot be taken back into X-Designer but they do allow you to make quick, simple adjustments right where they are needed.
If you do not wish to generate dialog templates, X-Designer generates code containing absolute values for sizes and positions as they are at the moment of generation. So, for example, if you have a PushButton that is 100 pixels wide, 30 pixels high and is located at 10, 200 then those explicit values will be used in the Microsoft Windows code, even though you have not explicitly set the x, y, width and height resources but allowed them to be calculated by the Motif toolkit. In practice this gives very good results--generating Microsoft Windows dialogs which look very similar to their Motif counterparts.
Because X-Designer is generating an absolute size for a Microsoft Windows control, it is important that the size of a dialog is appropriate for any font that will be used for text displayed in it. The best way to ensure this is to make X-Designer use a similarly sized font to display the dialog while it is being designed. There are two ways to do this.
The first way is to force the control to use a particular sized font, perhaps by setting the XmNfontList resource for the control or by setting the appropriate font resource on the shell. Consequently the dialogs will be similarly sized.
Alternatively use a resource so that X-Designer displays the design windows with a font that approximates to the default font used on Microsoft Windows. This will cause X-Designer to generate absolute sizes that are appropriate to the font. The Motif code will use a default font in the normal way. To make X-Designer use a specific font for the design on Microsoft Windows, use settings similar to the following in your resource file:
These values may work well for you, but it will depend on the precise font used on your Microsoft Windows system. It is the size and average width values which are important.
In Microsoft Windows mode, X-Designer generates OnSize message handlers to provide some resize behavior when the user resizes a dialog. X-Designer does not attempt to reproduce exactly the Motif geometry management, rather it generates a handler which will simulate the resize behavior of certain manager widgets. In particular, these are:
These managers do not need to be classes in order to produce the resize behavior; X-Designer generates a handler for the enclosing class that handles all descendant widgets. You can suppress the generation of the resize handler if you want to provide your own (through a sub class for example), by unsetting the MFC OnSize handler toggle on the Code generation page of the Core resources dialog. See FIGURE 11-9.
In order for a font to be generated into the Microsoft Windows code you must use font objects. This is because fonts must be persistent on Microsoft Windows. Only by using font objects can you guarantee this. X-Designer provides a visual cue by making the Apply button pink if you select an item from the list of fonts in the font selection dialog. If, however, you select an item from the list of font objects, the Apply button is no longer pink.
If you specify fontlists for your objects in X-Designer, the first font in the list will be used for the object on Microsoft Windows. Compound strings containing a mixture of tags will be translated to Microsoft Windows using only the first font specified.
Fonts in Microsoft Windows are named using a different mechanism from that used by X Windows. However, Microsoft Windows has quite a sophisticated matching algorithm. So, although X-Designer uses a fairly crude mapping to translate the font specification, even if you specify a font which is not available in Microsoft Windows, it will probably be substituted with something that looks reasonable.
Pixmap objects created in X-Designer are converted into a Microsoft Windows bitmap or icon (depending on whether the object is a button or label respectively). This is done for you automatically when you generate a Microsoft Windows resource file. X monochrome bitmaps are not supported in the translation to Microsoft Windows.
When you select "Microsoft Windows Resources" from the Generate dialog, X-Designer informs you that it will create a resource file and a bitmap/icon file for each pixmap you have created. Bitmap files are generated with the suffix ".bmp" and icon files with the suffix ".ico". You never need to save the pixmap to a file for Microsoft Windows but you may wish to do so for the Motif version. Note that icons are always scaled to 32x32 pixels on Windows.
For a Motif Button with a pixmap type label, X-Designer generates a CBitmapButton for Microsoft Windows. One difference between buttons with pixmaps on Motif and CBitmapButtons on Microsoft Windows is that CBitmapButtons have no border--in fact they do not look like buttons at all. You may, therefore, wish to incorporate a border in your pixmap design.
You can set the Background and Foreground color of a widget which will be mapped to an object on Microsoft Windows. These colors will be generated into the Microsoft Windows code in terms of their RGB (Red, Green, Blue) values. Microsoft Windows does not normally have the richness of color that is commonly available on X/Motif. For this reason the colors may not look identical on the two platforms. By default, however, the colors for the Microsoft Windows 95 "look and Feel" are used.
Specify the Background and Foreground colors in the usual way in X-Designer. Background colors must be color objects--Foreground colors do not have to be.
X-Designer can be extended to support widgets from any other Xt toolkit in addition to the default Motif set. Widgets added to X-Designer are called user-defined widgets or third party widgets. Chapter 23 provides a detailed description of this topic. The new widgets appear in the X-Designer widget palette and can be used in the same way as the pre-defined Motif ones.
Although, in Microsoft Windows mode, X-Designer does not provide explicit support for third party widgets, X-Designer's C++ model allows you some flexibility in this area.
X-Designer automatically treats third party widgets as though they are an instance of the class from which they are derived. So, for example, if you have a third party widget derived from XmPushButton, X-Designer will add it to your design as though it is an XmPushButton. X-Designer will then generate Motif XP code which is based on the CButton class, since this is the way XmPushButton is implemented in the Motif XP, to create an instance of your third party widget. The Microsoft Windows code will be exactly the same as if you had used a PushButton.
The example above uses the XmPushButton class which is a class supported by the Motif XP. If, however, the third party widget is derived from a class which is not supported by the Motif XP then X-Designer cannot handle that widget and will not generate code for it. In this case, you should use the strategy outlined in the following section.
If X-Designer's default behavior for a particular third party widget (described above) is not satisfactory, you can use the flexibility of the C++ model to enhance X-Designer's behavior. There are two steps:
1. Decide on a sensible mapping from your third party widget to a Windows control--whether that is a builtin MFC class or another third party component.
For example, many third party widget sets contain a ComboBox widget; this would clearly map through to the builtin MFC CComboBox class.
2. Tell X-Designer the name of the class it should use.
On the Code Generation page of the Core Resources panel, specify the C++ class structure to be generated for the selected third party widget. X-Designer fills this page in with its own mappings for the Motif components, but does not always know what to do with third party widgets, simply generating a basic Canvas in its place. All you would need to do here is to override the suggested classing with the mapping you feel is appropriate, and X-Designer will generate code accordingly. This means you will get an object of the right type rendered into your MFC code.
On the UNIX side, you would need to include a dummy class so that the code compiles there also for either pure Motif C++ or Motif XP, depending on what you want. The following is an illustration of the code you would have to add:
For generating Motif XP, you could also extend the Motif XP library. See Enhancing the Motif XP for details on how to do this.
With third party widgets which it does not understand, X-Designer has no way of knowing which Motif resources map to which MFC resources. For these widgets you will probably have to add the code for their resources by hand. Here are some possible strategies:
1. Put all the third party widget resources into Loose Bindings so that they go into the X resource file and are maintained inside X-Designer, thus working well on the X side. Then hand-edit the MFC resource file for similar purposes. See Loose Bindings for more information on how to create and use Loose Bindings.
2. Generate code on Unix with resources and the code options appropriately set, then generate no resources to code for the third party widgets and again maintain the MFC resource file by hand.
3. Specify a code prelude to add the resources you need. This can have anything you like in it, so you could do something like the following as a pre-manage prelude (assuming my_text is a class):
The Method Declarations dialog has an extra feature when in Microsoft Windows mode. There is a toggle button labelled Microsoft Windows MFC.
This toggle is used to denote whether the method is declared in the class structure of the enclosing class when generating Microsoft Windows code. When generating Motif code, the method is still declared in the enclosing class. The enclosing class is the nearest ancestor which has its structure set to class (either explicitly or automatically).
This toggle does not indicate whether or not the method appears in the Microsoft Windows code stubs--the Callbacks dialog indicates this. If, in that dialog, the method callback has an asterisk (*) appended to it, it will not be generated into the Microsoft Windows stubs file. The Microsoft Windows MFC toggle gives you control over the method declarations, although you would usually use the default that X-Designer provides. Use the Method declarations dialog to declare methods in a class of your choosing or declare them in one of your own classes. They must be declared somewhere.
When you add a method callback in the Callbacks dialog, if the method has not been declared already, X-Designer will declare it for you in the enclosing class. If you do not wish the method to be declared there, use the Method Declarations dialog to unset the Microsoft Windows MFC toggle.
If a DrawingArea is not the child of a ScrolledWindow, MainWindow or Shell it is created as a basic CWnd class--otherwise it is ignored for Microsoft Windows code generation. See Mapping Motif Widgets to Microsoft Windows for more information.
The Motif XP class library does not include any drawing support; any you require will be platform specific. However, X-Designer does allow you to add callback methods which by default are only declared for Motif flavors and Microsoft Windows message handlers. When in Microsoft Windows mode X-Designer adds a set of additional toggle buttons to the DrawingArea resource panel which can be used to add a Microsoft Windows message handler in the generated code.
If, for example, you were to select the OnRButtonDown toggle in the panel pictured above, the following stub is added to your callback stubs file:
Note that afx_msg is a pseudo keyword on Microsoft Windows. The following lines are added to your C++ externs file:
//{{AFX_MSG(scrolled_win_c) afx_msg void OnRButtonDown( UINT nFlags, CPoint point ): //}}AFX_MSG DECLARE_MESSAGE_MAP () |
This registers the message handler with Microsoft Windows.
X-Designer generates an instance of a CWinApp class to the MFC C++ flavors to represent the application. You can configure this class by means of the Application Class dialog which is displayed from the Module Menu. FIGURE 11-12 shows the dialog.
Event Handlers explains how X-Designer allows you to add event handlers to widgets in your design. Most of the event masks available for Motif widgets can be mapped to Windows code. The following table shows this mapping.
File names on the PC are restricted to 12 characters in total (including the dot) which must be distributed as no more than eight before the dot and no more than three after. If you wish to share files between the two platforms, this restriction will have to be kept in mind when generating Microsoft Windows code. Remember, also, that MS-DOS and Microsoft Windows are not case sensitive. Do not rely on upper and lower case letters to distinguish filenames.
The above restrictions should also be remembered when naming pixmap objects. When you ask X-Designer to generate a Microsoft Windows resource file after you have created pixmaps, X-Designer automatically generates Microsoft Windows bitmaps and icons in separate files using the name you specified in the pixmap editor. If, therefore, you have specified a name with more than eight characters, you will encounter problems on Microsoft Windows.
Different compilers have varied conventions acceptable on filename extensions. The suffix `.cxx' seems to be universally supported; most compilers should support `.cpp'; some compilation systems may accept `.C' and `.c++'. Visual C++ will complain if you specify `.c' for a file which contains C++ code.
See Setting the Filename Filter for details of how to change the default filters in the Generate dialog.
No makefile can be generated for the Microsoft Windows code files. Since make is a UNIX utility, it is assumed that you will be using a Microsoft Windows development environment (such as Visual C++) to build your application.
|
Note - If you are using Make on your UNIX platform, it is best to generate different code flavors into separate directories in order to avoid confusion and name clashes. |
There are a number of points connected with code generation which you should understand before generating code. These are detailed in the following subsections. Briefly, they are:
When you generate code for MFC, the Generate Options dialog (displayed by pressing the "Options" button at the bottom of the Generate dialog) contains a toggle labelled "Generate as Resources". This is shown in FIGURE 11-13. When this toggle is set, X-Designer generates the dialogs in your design as dialog templates, which are Microsoft Windows resource files describing the dialog. X-Designer generates some MFC code to fetch widgets out of the dialog templates and to control the dialogs, thereby generating a complete application. If the "Generate as Resources" toggle is not set, plain MFC is generated for your design. By default, the toggle is set.
Using dialog templates gives you the following advantages:
Designs for which resource files (or dialog templates) are generated are dialog based. They do not have a main Frame window. This gives you a much closer correlation between what you see on Motif and what you see on Microsoft Windows.
In the generated code, a Session Shell or an Application Shell inherits from a CDialog. This means that pressing <Enter> when the dialog itself is selected closes the application. Because of this, two of the dialog's methods are generated to the stubs file to be overridden if this behavior is not desired. The methods are OnOK and OnCancel. As with all methods in the stubs file, anything added to them is retained when code is regenerated.
When you generate any type of MFC code for Microsoft Windows, you can also generate project files for use in Microsoft Visual C++ using the base name specified in the Generate dialog. To make X-Designer generate project files, check that the "Generate Project Files" toggle is set in the Code Options dialog.
To use these, open the main project file (with the suffix "dsw") in Microsoft Visual C++. These project files are suitable for Visual C++ version 5 and later.
X-Designer has to store the widget id numbers in the save file for definitions so that code can be correctly generated for instances which indirectly modify the layout of an unnamed component. This can cause a problem if the design is changed in a way which affects the widget ids (such as resetting) before the code is generated. X-Designer will detect such loss of synchronization and will prompt you to save the file.
In order for X-Designer to correctly generate layout information the dialogs need to be realized. X-Designer will automatically show and then hide any unrealized dialogs when Microsoft Windows code is generated. You may see the dialogs appear briefly on the display.
Any Microsoft Foundation Class (MFC) code generated by X-Designer which contains Japanese text needs to be post-processed before it is compiled under Microsoft Windows.
A filter utility, xdtosj, is provided as part of the X-Designer release to perform this conversion. xdtosj converts the MFC code from EUC to Shift-JIS encoding and changes the DEFAULT_CHARSET value in the MFC CFont creation method to SHIFTJIS_CHARSET.
xdtosj is used in the following way:
xdtosj [-xf*] [file]
The following table describes the arguments.:
There are a number of application resources which apply to X-Designer in Microsoft Windows mode. One of these is the windows flag, indicating that X-Designer should start up in Microsoft Windows mode. This is described in Starting in Microsoft Windows Mode.
By default, X-Designer generates code for Microsoft Windows which adds Ctrl-M as the carriage return before the linefeed character. This character is expected by MS-DOS and may, therefore, be expected by your file transfer program. If, however, you do not wish to have these characters at the end of each line, make the following change to the X-Designer resource file:
xdesigner.mfcCarriageReturn: false
By default, X-Designer indicates that a field in a resource panel, or a button or any other text field, is not applicable to Microsoft Windows by coloring it pink. This color can be changed by altering the following line in the X-Designer application resource file:
xdesigner.mfcTextWarningBackground: #ecc9c9eacdda
The example above shows the default file entry--i.e. the color pink. You can change this large number to a more readable color name.
In the Generate dialog, X-Designer provides a default filename filter in the Filter text field. You can change this in the application resource file. Search for the following:
xdesigner.c++Filter: *.c
xdesigner.c++StubsFilter: *.c
These are the default entries for Motif code generation--both vanilla Motif and Motif XP. For Microsoft Windows code generation there are two extra filename filters:
xdesigner.visualC++Filter: *.cpp
xdesigner.visualC++StubsFilter: *.cpp
If you wish to share code between the two platforms, you might consider changing the filename filters for the two different flavors so that they are the same. See File Names for more details about points to bear in mind when naming files intended for both platforms.
Pinking is only discernible on a color display.
| X-Designer User's Guide | 817-5581-10 |
|
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.