Class Designer Design

This pages is reserved for the discussion about the design and features for the Class Designer. Please use lines to keep your posts separate. Occasionally, someone will refactor all of the comments into easier to read categories.

My current vision for the Dabo IDE is one where there are 4 separate but connected components; the visual arrangement of these components is not yet determined. By this I mean perhaps we can have all of them in a single frame, like Visual Studio does, or in separate windows.

The four components of the Designer are:

• The Form/Class Designer Surface. This is the visual representation of the end result, with controls appearing as they will at run time.
• The Object/Layout Tree. This is a hierarchical depiction of the class being developed. For a container-type object such as a form, it will be critical for navigating both the object containership as well as the Sizer arrangement. It will also be the only way to select a sizer for editing its properties. For single-object classes, such as textboxes and buttons, this will probably not need to be visible.
• The Property Sheet. This will display the properties for the currently-selected object in the Design Surface or the Layout tree, and allow editing of that selected item.
• Code Editor. This could either be a series of separate editor windows, or a single tabbed window, with a tab for each method being edited.

One of the goals of this design is to make the components adaptable to various uses, such as menu design. Each object being designed would have to be able to expose the PEMs it has available, so that the Property Sheet would know what to display; they may also have to use custom subclasses of the Tree, since only container controls will have any use for the sizer layout of the Tree.

To coordinate these components, there needs to be a central object through which all messaging can pass. I think it would be best to create a subclass of the Dabo dApp object for this purpose.

Depending on which component the user is interacting with, there are several events that can occur. I'm listing them here grouped by their origin in the IDE. Many of these events result in a general Selection Event, which will be received by each component of the IDE so that they may update themselves appropriately.

• Design Surface Events

  • Object Added/Deleted

    • => Tree: update contents
    • => App: selection event
    • Note: if we go with a strict sizer-based approach, it may be the case that we can only add objects to open slots in the sizer. If that's the case, then only deletion events will happend in the Design Surface.

  • Object(s) selected

    • => App: selection event

• Tree Events

  • Object Added/Deleted

    • => Design Surface: update contents; layout
    • => App: selection event

  • Object(s) selected

    • => App: selection event

• Prop Sheet Events

  • Property Value Changed

    • => Design Surface: update object display

  • Edit Method

    • => App: open Code Editor Window

• Code Editor Events

  • Window/Page Closed

    • => App: update stored object code

• Selection Event

  • Received by each component, which reacts accordingly:

    • Designer Surface:

      • Removes visual selection indicators from existing selection
      • Adds visual selection indicators to current selection

    • Tree

      • Same as for the Designer Surface, with the additional requirement that if the node for the selected object is hidden, the tree be expanded to show that node.

    • Prop Sheet

      • The Prop Sheet will query the object for its available PEMs?, and display them accordingly
      • It will also query the App object to find if the selected object has any existing method code so that it can visually indicate that.
      • If there are multiple objects selected, the Prop Sheet will repeat the above for each object. It will then display only PEMs? that both have in common.

    • Code Editor

      • no effect

The App object will have to store all the method code for every object. When an existing file is opened for editing, the App will have to parse out any existing method code and store it