Delphi Programming

and software in general.

Tuesday, August 19, 2008

FDCLib - Wizards without the black magic - part 1

It is time to get started with another contribution to the FDCLib.

Frames are great, but they can require a bit of fiddling to work well. The plan is to create a simple system to organize frames for tabbed views and wizards and simplify some of the design problems related to visual inheritance as well as class inheritance.

Design goals
1a. Each frame must not need to descend from the same class
1b. It must still be possible to extend frames by inheritance
2a. Each frame should not need to contain extensive knowledge about other frames
2b. Each frame must be able to obtain knowledge about/from other frames
3. Each frame should have (optional) input validation
4. It must be possible to make reusable frames such as file pickers, etc.
5. It must be possible to use the frames in different contexts (modal or modeless, window or dialog)

Using a similar approach to what I did for the grid controller, I will wrap myself around a basic TFrame and grab hold of the hooks that exist and move the business logic into a non-visual class known as TFrameWrapper.

To organize these non-visual classes, I will create a TFrameController. The frame controller will hold the knowledge about how the frames are to be presented, organized, and navigated.

Teaser: The frame controller will be reused in a future part of FDCLib. What part of the application do you usually need first, but often end up writing last? No, not the documentation :P - we are talking about code after all :)

Before I move on - I'd like gather some intel about how you are using frames today.

Your comments will be greatly appreciated!

5 comments:

  1. I've a similar system already up.
    but all my frames inherit from TSimpleFrame
    which is a simple frame with interface ISimpleFrame added.
    I handle all my frames via Interfaces, and for now ISimpleFrame contains only the procedure Display.

    Descendant frames can have more specifics interfaces.
    I think working with interfaces simplify greatly the creation of a frame manager.

    ReplyDelete
  2. I have been down this road also (see my TFrameManager component at http://www.threefishsoftware.com/tfcomponents.htm) but lately have found that decending from TForm and embedding that is simpler and has less side effects. There are a few problems which need to be overcome that occur with tab order, and accelerator keys.

    ReplyDelete
  3. @SKamradt: I will resist the temptation to download and inspect :)
    I hadn't actually thought about the accelerator keys, though. Good point.

    @Damien: I was initially thinking about using interface(s), but wanted to get around the whole inheritance requirement.

    ReplyDelete
  4. Like Damien, I've implemented TFrame via Interface. I've added too, OnShow and OnHide events... Precious for my use.
    I'll be very curious to see how you'll implement this task. TFrame is a very convenient component. I really like it !

    ReplyDelete
  5. Like Damien, I've implemented TFrame via Interface. I've added too, OnShow and OnHide events... Precious for my use.
    I'll be very curious to see how you'll implement this task. TFrame is a very convenient component. I really like it !

    ReplyDelete