2

I have a utility routine that I call when validating user input in a dialog fails. It sets focus to the offending control, beeps and displays an appropriate message to the user. This works well as long as the offending control is not hidden. Now I have to adapt this to a situation where the relevant controls are children of some kind of collapsible group boxes (possibly even nested), and I have to make sure that the "ancestor" boxes are expanded before calling SetFocus.

Now I have a few possibilities:

  • Build knowledge about the collapsible component into the error reporting routine. I'd like to avoid that as the routine should rather stay generic.
  • Pass an callback that can be called prior to (or instead of) SetFocus. This is error prone because one has to remember to pass the callback at all the relevant places.
  • My favourite solution would probably be an event (or overrideable method) (probably in TWinControl) that tells a container control "please make sure you and you child controls are visible" but I don't know of such a thing.

Any ideas how I can handle this situation?

Uli Gerhardt
  • 13,748
  • 1
  • 45
  • 83
  • FWIW, as a user, I would be pretty surprised if I pressed 'Save' and suddenly gadgets around the form start moving/expanding. I'd like a notification instead. Just my view... – Sertac Akyuz Feb 10 '11 at 15:27
  • I don't know. I guess I would be annoyed if an app tells me "You have entered invalid data. And I know where the control you're looking for right now is but won't show you." :-) – Uli Gerhardt Feb 10 '11 at 15:38
  • Sertac has a point! Changing selection, expanding trees, moving stuff around would cause the user to "lose context": they'll have a "what - what - where am I now" moment when you do that. A better idea would be to validate data when it's about to be hidden, while the user's still focused on the task at hand. For example, validating the controls on the current TabSheet in a PageControl's OnChanging event, and blocking the change if there's a problem. – Cosmin Prund Feb 10 '11 at 15:45
  • @Cosmin @Sertac @Ulrich I'm really not sure it's as simple as you are making out. Sometimes it's best to do it one way, sometimes the other. I fully appreciate Ulrich's point that if the program knows where the problem is then it is great to show it. I'd be asking questions about expandable UI which I'm not a big fan of. But then what do I know about the app in question?!! – David Heffernan Feb 10 '11 at 15:54
  • @Cosmin: Your approach might be the middle ground between validation in OnExit (evil if you have interdependent and Windows doesn't like it that much) and validation before commiting which yields my current issue. I have to talk about it with my colleagues. :-) – Uli Gerhardt Feb 10 '11 at 15:54

3 Answers3

4
  1. Define an interface with a method called something like: EnsureVisible.
  2. Implement it for all your components (you may need to derive your own versions of some of these components). This allows different controls to have quite different behaviour.
  3. When a control needs to make sure it is visible it walks its parents and calls EnsureVisible if the interface is implemented.

If you don't like interfaces then do it with a custom Windows message, but you get the basic idea.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • +1 for the concept of using customized versions of "all controls". One of those days I'd get around to doing just that, set up one huge package that contains derived versions of all the controls I use. One of those days... – Cosmin Prund Feb 10 '11 at 16:28
2

In my opinion the best solution would be a separate routine that builds knowledge about all container controls, allowing the dialog validation routine to stay generic and at the same time being focused enough to be easily tested and maintained. Something along the lines of:

procedure ForceControlVisible(C: TControl);
begin
  // Recursive code
  if Assigned(C.Parent) then ForceControlVisible(C.Parent);
  // Code specific to each container control class
  if C is TTabSheet then
     begin
       // Code that makes sure "C" is the active page in the PageControl
       // goes here. We already know the PageControl itself is visible because
       // of the recursive call.
     end
  else if C is TYourCollapsibleBox then
     begin
       // Code that handles your specific collapsible boxes goes here
     end      
end;

OOP-style methods that rely on virtual methods or implementing interfaces would be way more elegant, but require access to the source code of all the controls you want to use: even if you do have access to all required sources, it's preferable not to introduce any changes because it makes upgrading those controls difficult (you'd have to re-introduce your changes after getting the new files from the supplier).

Cosmin Prund
  • 25,498
  • 2
  • 60
  • 104
  • +1 - TTabSheet is an excellent example. And I'm not going to change the VCL sources. :-) – Uli Gerhardt Feb 10 '11 at 15:43
  • +1. One could replace the big conditional with a registry that manages something like `IVisibilityEnforcer`. I could then just say `RegisterVisibilityEnforcer (TTabSheet, TabSheetVisibilityEnforcer)`. This would make it easier to add behaviour for new controls. – jpfollenius Feb 10 '11 at 16:07
  • @Ulrich Sometimes you just have to change the VCL sources!! But it's best keeping it to a minimum, that's for sure. I tend to fix as much as possible by hooking and only re-compile only the bare minimum (I can get away with just 3 VCL units). – David Heffernan Feb 10 '11 at 16:09
  • When I read Cosmin's answer I immediately thought about a registry - I'm getting used to implement these. :-) (E.g. my solution to http://stackoverflow.com/questions/503079/how-to-link-parallel-class-hierarchy became a registry.) – Uli Gerhardt Feb 10 '11 at 16:12
1

Each component knows its Parent. You can walk up the list to make each parent visible.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Gregor Brandt
  • 7,659
  • 38
  • 59
  • 1
    Unfortunately `C.Visible := True` isn't enough. Depending on the type of C I have to additionally call `C.Expanded := True` or make sure that C is the active sheet of its PageControl etc. – Uli Gerhardt Feb 10 '11 at 15:45
  • I corrected your answer - you said `Owner` when you meant `Parent`. – David Heffernan Feb 10 '11 at 16:20