Introduction !DrWimpC Features DrWimpC library Examples


!DrWimpC Application Details Dialogue


This dialogue can be used to specify both compile and run time options for your applicaition. It is shown when a new application is created, or the Options menu item is activated in the applications action submenu

Complete the dialogue and click on the Accept icon to save the changes, or the Cancel icon if you do not wish to proceed with the changes.

The dialogue is arranged into blocks of options that refer to the same part of the application. The data from this dialogue is held in the application in a file called dcdefaults inside a directory called Defaults. The options can be changed later using this dialogue. for example, you may initially decide that the application's icon will be on the right hand side of the icon bar, but later set the Left Side flag to get the icon to appear on the left hand side. This doesn't require a recompilation of any code since the flag setting is held in the dcdefaults file which is read into a data area at run time by the DrwimpC during application startup - see the section Standard user wimp data for more details on this data area, which is available to your application at run time, and its values can be adjusted by your application prior to being used by DrWimpC library at applicatin startup. The user function drw_u_setup_uwdata() is provided in file drwapp for this purpose.

Similarly, you may initially specify that a standard icon bar menu be used (with items Info Help and Quit) by ticking the Std menu flag, but later define an icon bar menu in a message file, and by using this dialogue to unset the Std menu flag, and entering details of the menu's message token and message file, the message file menu definition will be used the next time you load tha application, again without any code changes or recompilation. This is because the DrWimpC library acts on the settings automatically, and for the bar menu will create it according to the settings given here. Likewise with the application's icon bar icon, main window - the window that is opened by clicking on the icon bar icon, the info and standard save boxes are also handled in this way.

The first section is general to the application. Here you may specify maximum values for data buffers allocated at run time by the DrWimpC library for its internal buffers - maxobjsize. There are a minimum of three of these bufffers and are principally used for file path names and command lines. It has a minimum value of 1024 bytes. You should set it to the maximum length of file path or command line you expect to encounter. The wimp block size refers to the likely maximum buffer length required to hold a window definition and its icons. This is not critical to get right as the DrWimpC library adjusts this internally as necessary. Message files is the default number of message files you want the DrWimpC library to allocate space for internal structures to handle them in your application. (Note: this mimics the BASIC DrWimp library. Since this manual was written a new way of handling message files has been implemented using a linked list instead of a fixed size array to store internal information about message files used by an application. So, this number is no longer relevant). The wimp version is the value passed to Wimp_Initialise. The Resources field is the name of the directory to hold the territory specific Resources, and should usually be left as Resources. (Note: since this manual was written the Resoources directory name is fixed as 'Resources'). The res prefix value is used if you want the resoource territory sub directories to be numeric prefixed by this value. the syntax validation string is not implemented yet. Basically it is for use with the os_read_args swi to input values from a parameter string that appears in the command to run your application, into a buffer that can be processed by your application.

The Second section is concerned with Icon Bar options. These options can be set at compile or run time, and changed later using this dialogue. The creation of an icon bar icon and icon bar menu is done automatically using the information from this dialogue by the DrwimpC library wimp initialisation before calling the drw_uw_init function (or its template function equivalent). The first two options let you determine if the application has an icon on the icon bar and which side of the icon bar the icon appears. If you don't want an icon bar icon, or wish to create it manually using yor own code in drw_uw_init(), then unset the has icon flag. Next is the icon bar text that will appear below the icon on the icon bar, and a maximum text length value for the memory buffer to hold the text. (Iconbar menu definition description removed. It has been replaced by the Defined Menus facility. Use the Defined Menus list dialogue to specify an iconbar menu Define or edit the default iconbar menu definition created by DrWimpC App Builder when you create a new applicatoon. It is nnamed 'Ibarmenu'. The DrWimpC library uses this definition to create an iconbar menu).

The next three sections have been removed. The facility to name the main window, info box, and standard save dialogue templates has been replaced by three corresponding flags in the templates menu. Ticking these flags identifies a template in a template file as the Main window, Info Box or Standard save box. You can create any of these windows manually instead, or not at all, in your application's wimp initialisation. If you use the temlates menu flags you can also select where the main window is opened, optionally get DrWimpC library to fill in the Info Box fields from the information given in the newapp dialogue, and linked to the icon bar menu's Info item. If you specify a template from the templates menu for any of these three windows DrWimpC library will load the window definition during its wimp initailisation and store their handles in the Standard user wimp data area and so the windows can be accessed in your code using these window handles.

The next section is the Application Resources details. Here you can drag files to the icon of the file's type to store them in the application directory, or in a territory sub directory in the Resources directory. (File's of types other than sprite, template and text can be dragged to the Other data icon). For sprite files, the merge sprite flag when set causes !DrWimpc to look for a file with the same name as the dragged file in the application and to load it and merge the dragged file's sprites with the current contents and save the result. This can be useful in replacing the default sprites in the files generated by the newapp dialogue !Sprites and !Sprites22 with the actual sprites you want to use for your application (in the filer display and on the icon bar).

The territory flags have a dual use. Firstly, they can be used to get !DrWimpC to store dragged files in a specified territory sub directory, by setting the Use territory name and/or territory number flags - if both are set then the use territory name flag takes precedence. The territory to save to is selected from the Save to territory pop up menu. you can also get !DrwimpC to create the territory sub directory in your application by ticking items in the territories pop up menu.

The second use for these flags is to set the save values in the dcdefaults file. The DrwimpC library will use these settings at application start up when searching for your application's resources (message files, etc). As with other settings your application can override them in the user function drw_u_setup_uwdata().

Finally, in this section, the two flags Open App msgs and Use Lib msgs file when set indicate that the DrWimpC library application initialistion code should try to load your application's messages file, and use a libmsgs file for its own error and warning messages. (The libmsgs messages have a hard coded english version which is used if the Use Lib msgs file is not set, or a libmsgs file cannot be found. So, by this mechanism foreign language libmsgs to be used).

The miscellaneous section only has two icons. The second is for the name of a data pointer that is passed to the automatic function registration routine. The idea being that this is passed to the registered function when it is called. However, I haven't found an efficient way of specifying an application header file that defines the data pointer to be included in the file containing the call to the registration function. I've also developed a more versatile way of specifying such data handles and the template object function's data pointer is also passed to template functions using this field. Therefore, for this release, this value should be left as NULL.

The first icon in this section is only present because of the way !Zap redraw oriks (and also but separate to !Zap, the way OLE works)s . In order to get !Zap to operate with !DrWimpC using the external edit mechanism I have included this delay element. This is so that when defining template functions by clicking on the template icon the sequence of events to load an exsting file into !Zap, using the external edit protocol, then sending the function definition to !Zap to be added at the end of the file in the window that !Zap creates for the external edit, I have to wait on null events until !Zap creates the window and opens it so that the place cursor at end of file message (extedit_cursor) is received at the correct time. !Zap works differently to !StrongEd, opening its window for the external edit earlier than !Zap does, so the extedit_cursor messgae can be sent without this delay. The reason for having a variable delay is that I have found that larger files need a larger delay before !Zap gets the extedit_cursor message and places the cursor correctly, so you can adjust it if necessary. Although, I have tested source files up to about 300k with the default setting of 200 and found no problem. You'll see what I mean when you try it, but only if you use !Zap. I explain it by reasoning that the !Zap redraw window code operates differently to !StrongEd's method.

Similarly, editing templates from DrWimpC App Builder uses OLE and the edit window must be open when DrWimpC App Builder sends a mouse click to it to get the temalte editor to open the template for editing, so DrWimpC App Builder has to wait for the window to open for a successful OLE template edit to begin. This is what the OLE retry field is for in DrWimpC. It also serves as a limit for any DrWimpC application before the DrWimpC library stops attempting to start an OLE edit.

I have also added a similar retry limit for external edits.

[Top]