From a "functional" view, there are 2 basic types of "windows" in the UI - the Browse and the Form.

 

A classic paradigm for a browse is a window that shows Product records.

From this window we can query or search the products database, add a new record or select and edit a product record. The editing is done inside the browse [with the help of a table control] _OR_ it can be done in separate windows of the Form type.

This "paradigm" is nothing new - it has been around for a long time - and many classic RAD tools, like Clarion, have used it with great success.

​

Now all alpha360 UI windows, Browses or Forms, are always:

  • WD Internal Windows - autonomus, with their own buffers [independent HFSQL context]
  • embedded inside dynamic tabs
  • controlled by just 2 UI procedures
  • they NEVER have ANY kind of CRUDE operations inside them
  • and ALL of them, are procedures, with just one parameter of type ST_a360_DynamicWindow

​

All Browse windows have the same "visual design", the same set of local procedures and the same "behavior and workflow", without the use of templates. This is true for the Form windows also.

​

The only windows - inside the UI - that are NOT internal windows are a the lookup windows.