GWenerator

Welcome to GWenerator, a code generator that translates a Resource Compiler script file (.rc or .dlg) into an Ada package for the GWindows GUI framework.

The Copyright statement appears in the tool's human-written source files: RC2GW.adb, RC_Help.ads, RC_Help.adb, RC.l, RC.y.

  1. Presentation
  2. Quick user guide of GWenerator.exe
  3. How to build the tool
  4. How to build the demo / test applications
  5. Web resources to this project
  6. To-do list
  7. List of changes
  8. Thanks
  9. Contact
  10. Annex 1: Configuring the resource editor, ResEdit, for GNAT
  11. Annex 2: Goodies: open-source packages that may be useful for your GWindows application
  12. Annex 3: Examples of applications developed using GWindows and GWenerator
  13. Annex 4: Configuring a resource within Visual Studio for the GWenerator
  1. Presentation

    GWenerator is a code generator that translates a Resource Compiler script file (.rc or .dlg) into an Ada package for the GWindows GUI system.
    This tool comes in two "flavours":

     
    GWenerator doesn't pretend to be the ultimate tool, but is rather there to fill the gap between visual GUI design and the wonderful GWindows programming framework. Fortunately, there is a way, though not perfect, nor complete, nor interactive, to separate the GUI design and the code generation. This way is the Resource! There are many Resource Editors for Windows, for more than 27 years (in 2016). It ranges from the antique DlgEdit to Visual Studio 2015 for the editors provided by Microsoft. In the freeware or open-source world, there are also some, e.g. ResEdit. What was missing, to benefit from that source of GUI design, was a parser for the resource script files. It is precisely around such a parser that GWenerator is built.

    GWenerator translates those resources that are meaningful to be translated, that is:

     
    Typically, a resource like XYZ.rc will be translated into XYZ_Resource_GUI Ada package (.ads and .adb), that can be "with"-ed from your application, for instance XYZ.adb. Note that the graphical interface of the tool is build through the tool itself! It means that looking at GWenerator.rc and the GWenerator_Resource_GUI gives you a good example of what are the inputs and outputs.

    The advantage of having a tool like GWenerator instead of using the resource items directly is that once these resources are as GWindows code, they can be transformed dynamically (e.g. status of dialog items, recent file list menus), and benefit from the high-level, object-oriented, safe, and easy to program framework of GWindows. Edit box contents can be set or read without needing interfacing C strings. You can program within the GWindows type system. You don't need to mix GWindows with tricky, low-level Win32 elements as when you are using the resources directly.
    It is also perfectly possible to mix dialogs or menus from the GWenerator tool and other GWindows elements which have been programmed in a "non-visual" way. After all, the compiler cannot distinguish what is automatically generated and what is typed by hand.

    Eventually, parts of the generated code can be reused for more profound transformation or automation, but in most cases the link [graphic edition → automatic code generation] would be better to be kept. For dynamically adding dialog items, better to use the inheritance from the generated object types.

    Here is a schema describing which tool generates which file when building an application:

    Schema

  2. Quick user guide of GWenerator.exe

  3. How to build the tool itself (obtain the executables of rc2gw or GWenerator):

    You need an Ada compiler (Ada 95 or more) that compiles for Windows 32 bit. Only GNAT has been tested with GWindows, but probably any will fit.

    If you have GNAT installed, go to the "src" sub-directory and start "make.cmd". Then, the GWenerator.exe is built, as well as the command-line version, rc2gw.exe.

    For programming with the tool, you may want an installation of the GWindows system, although a full one is included in the RC2GW package (built for ANSI, i.e. 8 bit character applications).

    If you want to modify the tool, you may need to modify the RC.l and RC.y files, especially if you want to expand the grammar for new resource styles, options or whatever (the possible combinations are huge!). In that case, you also need to build "ayacc.exe" (via: "gnatmake ayacc.adb") and "aflex.exe" (via: "gnatmake aflex.adb") which are in the "ayacc95" and "aflex95" sub-directories. These executable have to be put into a directory callable from the PATH or directly into the "src" sub-directory along with the RC.l and RC.y files. Then, "make -r" recreates some Ada sources from the RC.l and RC.y files and builds rc2gw.exe using these new sources. If you are confused by these generators of code generators, you can also submit .rc files (or fragments) to the project coordinators and hope they will do something good with it...

  4. How to build the demo / test applications:

    Go to the "test" sub-directory and start "make_all.cmd". For each name mentioned in "make_all.cmd", you will get first a code generation for a resource (.rc) file.
    For instance GW_RE_App.rc will give a GW_RE_App_Resource_GUI Ada package (.ads and .adb). Then an application will be built (GW_RE_App.exe).
    There are several resources tested:

    Additionally, you can look at GWenerator.rc in the tool's source directory (src), which is created with ResEdit. The application there is functional.

  5. Web resources for RC2GW:

  6. To-do list:

  7. List of changes:

  8. Thanks to...

  9. Contact:

  10. Annex 1: Configuring ResEdit for GNAT (Windows)

    Upon the first start of ResEdit, you may get the following message:
    Message

    This means ResEdit has no access to files such as "windows.h", that are needed.
    Just say "No". Then, go to Preferences,
    Preferences

    then General → Include paths:
    Include paths

    We assume here GNAT is installed in the directory "C:\GNAT\2015", just for example.
    You can see the actual installation directory in the PATH (command "path" in the command-line interface, cmd.exe)
    Then the include directory required for ResEdit will be "C:\GNAT\2015\i686-pc-mingw32\include".

    Advices about using ResEdit

    1. It is recommended to have a proper naming convention for the ".h" file containing the resource constants.
      It may be useful if you have several resource scripts in the same location.
      For instance the interface with "GWenerator.rc" has "GWenerator.h" instead of the default "resource.h".
      To that aim, in the preferences, put "%barefilename%.h" instead of "resource.h" as Header file name.
      Header file name
    2. Sometimes, the auto-resize feature of ResEdit is too narrow and the last word of some labels are cut out when rendered by GWindows. The solution is to switch off the auto-resize feature:
      Preferences → Dialog Editor → Control preferences → Auto resize controls: Never.

  11. Goodies: open-source packages that may be useful for your GWindows application

  12. Examples of applications developped using GWindows and GWenerator

    NB: some of these GWindows examples may use only partially GWenerator.

    1. Open-source applications:
      • AZip - A portable Zip Archive Manager :

        Tree view, search - click to enlarge

      • TeXCAD - A program for drawing or retouching {picture}s in LaTeX:

        Click to enlarge

    2. Commercial applications:
      • ElSch - Workflow manager :

        ElSch - click to enlarge

    3. Corporate (internal) applications:
      • Imaging toolset :

        Image Spy

      • A Portfolio Model for Natural Catastrophe Reinsurance (presented at Ada-Europe 2012) :

        PPM - click to enlarge

  13. Annex 4: Configuring a resource within Visual Studio for the GWenerator

    The following are observations with Visual Studio Community 2015, for Win32 C++ projects. This is a way to design user interfaces for GWindows. Just ignore the ".cpp" and many other files, they do nothing.