wxegen.exe is to re-call what dbschema.exe is for re-store and uigen.exe is for re-bind – a tool for automating programming chores.
In constrast to the latter two generators, wxegen.exe is not called by the programmer, at least not usually. wxegen.exe does its work (almost) transparently whenever the programmer changes one of wxegen.exe's input files.
The following pages explain what wxegen.exe does and how. For understanding the following discussion, these pages will be helpful (read in this order, if you haven't done so already):
As you can see in this screenshot, wxegen.exe is called by Visual Studio as a build event in the web-project as generated by uigen.exe, the web-project generator:
The complete line of invocation is
\PhoneBook\Remotion\net-3.5\bin\Debug\wxegen \
UI\*.aspx.cs \
WxeFunctions.cs \
/prjfile:PhoneBook.Web.csproj \
/functionbase:PhoneBook.Web.Classes.BaseFunction
The most important parameters here are
UI*aspx.cs(input files)WxeFunctions.cs(output file)
because they might give a sense of what wxegen.exe does already. A reference of parameters and how to invoke WxeGen on the command line can be found here: using wxegen.exe on the command line (just for completeness, you won't use wxegen.exe on the command line).
wxegen.exe processes the input files, looks for "annotations" in the source code and adds extra properties and methods to the ASP.NET pages (the input files, parameter item 1 in the list above) that make each page behave like a re-call function, i.e. gives the programmer the convenient illusion that he is dealing with a callable function, complete with local data and a return stack. These ASP.NET page-class supplements are written to the output file (item 2, per default named WxeFunctions.cs) and compiled in your project.
The next section will explain why this is desirable. Page Pick location, the page function explains how this works with an example from the PhoneBook tutorial.
re-call "functions" are ASP.NET 2.0 pages
Programming transitions from one page to the next in conventional ASP.NET 2.0 works like GOTO-programming from a forgotten era:
- if the user clicks on a link, follow the link and GO TO that page
- for remembering from which page you came from you have to remember that page yourself
- for passing data between pages, you must resort to global "variables"
Mature programmers who have been there, done that, might feel nostalgic about this type of web programming, but at the same time will probably admit that the late Edsger W. Dijkstra was on to something.
Note that going to a web-page with the likely plan to return to where we came from is a frequent phenomenon in form-driven applications people build with re-motion. Users open a form, decide that "sub-elements" must be edited, "sub-forms" must be opened, often more than once. In re-motion, the flow of control often resembles the work of modal dialogs in Microsoft Windows:
The boss-car-fax unit of work from the re-motion components overview can be understood in a similar fashion – "stacked" windows with built-in return automation:
Such modal dialogs are not programmed with GOTOs, they lend themselves well to procedural programming, and this is what re-call offers here. It brings procedural programming to ASP.NET programmers, complete with
- callable functions (called "page functions", or "WXE functions")
- typed parameters (called "wxe parameters")
- typed local variables (called "page-local variables")
- typed return values (boringly called "return values")
A very complete example including all these features is the Pick location form in the PhoneBook application. This form is a re-call function, of course. You can find a detailed discussion of Pick location here: Pick location, the page function.