开发者

Make sure nested child control is visible

开发者 https://www.devze.com 2023-02-09 14:13 出处:网络
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 lon

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?


  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.


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).


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

0

精彩评论

暂无评论...
验证码 换一张
取 消