Sw4   >   Windows   >   Windows


This section covers topics related to window instances and window classes.

Window Instances List Editor

All window instances in StudioWorks must included in the oWindows master list before you can open an instance of the window. Each module adds their own window instances to the master list. The window instances lists are returned by the $:WindowInstancesList property method of the oWindowList objects.

StudioWorks automatically declares a default list and edit window instance for each schema class in your application. For example if you have a schema class named sAuthor with a server table name Author, StudioWorks will automatically declare the window instances AuthorList and AuthorEdit for you. Each window instance is called a wininstid and must be unique across all modules.

For each default window instance StudioWorks automatically sets its sqlclassname property by searching for a query or schema class based on naming conventions. The following example is for the AuthorList window instance:

  1. qAuthorList - if found uses it. (For AuthorEdit StudioWorks looks for qAuthorEdit)
  2. qAuthor - if found uses it.
  3. sAuthor - uses the base schema class if one of the above query classes is not found

You add/modify/delete window instances using the Window Instances List Editor located under a tab of the Window Instances Browser. Instruction are provided in the editor window. If you change any of the properties of a default wininstid you become responsible for all further changes.

Tooltips are provided for the various fields (window instance properties) of the Window Instances List Editor.

Default Commands

attachChangeRecordObserverYou can set default commands to be excecuted when an evOK or evCancel is received by the wShell window.

The wShell window's $event method traps On evOK and On evCancel and sends a $doCmnd(pCmnd) message to the current subwindow. The pCmnd parameter is set as follows:

The $doCmnd method, checks for pCmnd = to 'defaultokay' or 'defaultcancel' and changes the parameter value to the return value of $:DefaultCmnd_evOK or $:DefaultCmnd_evCancel as applicable.

The base window defaults have been set to the following:

If you want to change the defaults you can either override the $_constructSetDefaultCmnds method in your subclass window, or you can set the values by sending using the $:DefaultCmnd_ev...$assign method.


You should place your edit fields for any edit type subwindow inside of a kScrollbox object named MainScrollbox. (The exact name and case is important.)

The reason for doing this is to allow the edit fields to scroll independent of the swToolbar subwindow field which is normally at the top of an edit type subwindow.

If we were to set the entire edit subwindow field to scroll, the swToolbar would scroll off the top if user scrolled down the subwindow field. The solution was to put all of the edit fields inside of a kScrollbox field, thereby allowing the user to scroll down the MainScrollbox field without affecting the swToolbar field.


When you Developerize a wEdit_autoconfig window, StudioWorks automatically adds the MainScrollbox for you and puts the edit fields inside the scrollbox.

If you have an edit subwindow that does not scroll when it should, you likely need to add a MainScrollbox field to the subwindow. Here's what to do:

  1. Add a kScrollbox field to the window class.
  2. Set the following properties of the scrollbox

    $name - MainScrollbox
    $fieldstyle - CtrlSubWindow
    $horzscroll - kFalse
    $vertscroll - kFalse
  3. Stretch the window class size, then stretch and move the kScrollbox field so that it is big enough to contain the edit fields.
  4. Move all the edit fields into the MainScrollbox.
  5. Set the $edgefloat property of the MainScrollbox to kEFposnClient
All going well the next time you open an instance of the subwindow vertical and horizontal scrollbars will appear as needed whenever the window is sized smaller than the space needed to display all of the edit fields.

Replace Shared WinInstID

There are several shared module libraries that are included with StudioWorks. You set whether or not to include each library in the $:AppLibsList method of oConstants. (See Configuration > App Libraries List)

When you include a library, the window instances declared by the library's oWindowList object are automatically added to your application's windows list and navigation menus.

You may have a situation where you want to modify or replace a window instance declared by a StudioWorks shared library. Making the change directly in the shared library would be a problem because StudioWorks updates would wipe out your changes.

One technique you can use is to add the exact same WinInstID to the oWindowsList object in your main library or one of your module libraries. For the WinInstID which you add, you would point it to your custom window class.

You then need to remove the shared library WinInstID from the master windows list. You can accomplish this as follows:

  1. Create a subclass of swGui4.oWindows in your main library.
  2. Point your main library startup task variable, wn, to the oWindows class in your main library.
  3. Override the $buildWindowsList method of oWindows and add code which runs the superclass method and them removes the shared library WinInstID. The following code snip gives you an idea of what the code would look like.

    ; Superclass builds the list of all WinInstIDs.
    Do inherited Returns FlagOK
    If FlagOK
       ; Find and remove the shared library WinInstID that is being replaced by a custom WinInstID.
       Calculate HomeLibName as 'swContacts4'
       Calculate WinInstID as 'PersonEdit'
       If iWindowsList.$search($ref.homelibname=HomeLibName&$ref.wininstid=WinInstID,1,0,0,0)
          Do iWindowsList.$remove(kListDeleteSelected)
       End If
    End If
    Quit method FlagOK