Re: command bars

Hi Jeff,

Of course, those were just some of the possibilities, but hopefully relatively simple ones.

One thing about WTL compared to MFC is that is brings you closer to the Windows API, which it basically wraps.  One reason I switched to WTL a while back was that I got tired of fighting MFC and all of it's assumptions and all of the workarounds needed to do anything "non-standard".  So, perhaps we could say that WTL is more of a "library" and less of a "framework"; e.g., it doesn't force you to do things a certain way.

Folks can correct me if I'm wrong, but my "view" is that in WTL, a "view" is just any window that can be created.  There is no special "View" base class.  An SDI frame window has some things that make it easier to assign a single "view" (e.g. a child window) and manage it (resizing, etc.) as well as support for command bars, toolbars, status bars, etc., but there is no special relationship between a frame window and a "view" other than a parent/child relationship.

If your side windows are fixed, seems like it would be pretty simple to draw them on a dialog resource and leave an empty space in the middle, then your dialog class (or "view") creates/shows/hides/destroys whatever window you need to appear in the middle part, making it a child of the view when it is created.

That seems simpler to me than using the frame, which is kind of designed for a single child view.  If you want to go that route, I'm sure it's doable.  There is an UpdateLayout function in the frame I think that might be a good point for modifying the default behavior and adding your side windows.  I don't think that the WTL command bar has all of the functionality you want:  I don't think it supports vertical bars like MFC does.  I'm not aware of anything built into WTL's main frame class that supports control bars or dockable windows by default.  You might want to search, e.g., on CodeProject, for WTL docking frameworks.  In MFC, the docking and control bar stuff is as much a part of the frame window code as the control bar code; this support doesn't exist in WTL's frame as far as I know
 .

As a note, splitter windows can easily have the panes set to fixed sizes.  This suggestion was simply because a splitter window has code already in it to manage the windows that appear in the panes, so it might be a bit less work for you.

Anyway, seems to me that all you need, and the simplest approach, is to have a view that has a "variable" middle window in a set rectangle and all you do is write some code to manage what window appears in that middle part.

~Mike

--- In [email protected], "Jeff Boeker" <Jeff@...> wrote:
>
> Hello Mike,
> 
>  
> 
> Thanks for surveying the possibilities.  The reason I initially thought of
> command bars is because when I used MFC in a similar project some years ago,
> I derived from CControlBar.  I hesitate to delve too much into the splitter
> windows because my side panels (windows) need to be fixed in size and
> position.  
> 
>  
> 
> My application will run in a fixed resolution so all the dimension are known
> ahead of time.  What I envision  is that the side windows are children of
> the frame window, just like a toolbar or status bar.  I initially thought of
> using #4 in your list which was why I was modeling my 'bar' after
> CCommandBar.
> 
>  
> 
> I'm a little unclear with the designation of the toolbar, status bar, etc.
> as 'custom controls'.  For ATL/WTL any non-view window is a custom control?
> 
>  
> 
> Thanks,
> 
> Jeff
> 
>  
> 
> From: [email protected] [mailto:[email protected]] On Behalf Of
> domehead100
> Sent: Tuesday, January 05, 2010 12:03 AM
> To: [email protected]
> Subject: [wtl] Re: command bars
> 
>  
> 
>   
> 
> Hi Jeff,
> 
> I don't see how this has anything to do with command bars.
> 
> Sounds like all you need is an SDI app with a "view" that is a container for
> different windows (left/center/right).
> 
> I would start with the basic app-wizard generated SDI app, and then look at
> customizing the View.
> 
> You could, for example:
> 1) Base your view in the app-wizard on a form view (which is a dialog-based
> view), and edit your dialog resource to build your left/right "windows" as
> just part of the view. Add resizing support (CDialogResize) as needed. This
> way the left/right "windows" need not actually be separate windows, just
> part of the containing view. The middle "window" could be swapped out as
> needed or could be a simple window that acts as a container for whatever you
> want the middle window to be.
> 
> 2) Do the above, but build your left/right windows as separate dialogs and
> then create them as children of the view. You can use static controls in the
> main dialog resource, then have an initialize function that gets the
> coordinates of the statics, destroys them, and creates your dialogs using
> the same coordinates. Again, resizing support would probably be needed.
> Note: if you use dialogs and create them (vs. DoModal), need to have a
> PreTranslateMessage handler that calls IsDialogMessage). One thing I often
> use is a function I wrote called "ReplaceWindow" that's similar to
> SubclassWindow but does the stuff noted above (e.g., creating my real
> window, getting the coordinates of some control on the dialog, destroying
> that control, creating my window in it's place). 
> 
> 3) Use splitter windows. The view could be a splitter or could contain a
> splitter, and either the left or right pane of the view could be another
> splitter that contains the left or right window and the middle window. This
> makes it easy to change the middle pane by creating whatever window is
> needed and setting is as that pane. I often create custom views that are
> subclasses of CSplitterWindowImpl (e.g., class CMyView : public
> CSplitterWindowImpl<CMyView, true>), so my view "is" a splitter window
> instead of containing one (makes things simpler).
> 
> 4) Create your own custom view just based on CWindowImpl/CWindow; e.g., a
> "ground-up" custom control. In it's Create it would create the child
> windows, position them, etc. Resizing support needed as well.
> 
> Anyway, lots of ways to skin this cat :o). I think #3 above might be the
> easiest. There are certainly other ways; but don't get overwhelmed, it's
> just windows that you have to create and parent/child relationships that you
> have to set up.
> 
> You might want to check out the "WTL for MFC Programmers" series on
> CodeProject (even if you're not an MFC programmer, it's a helpful
> introduction to things like dialogs, resizing, splitters, etc.).
> 
> ~Mike
> 
> --- In [email protected] <mailto:wtl%40yahoogroups.com> , "Rocinante0"
> <Jeff@> wrote:
> >
> > I want to create an application that has a fixed window on each side of
> the screen and in the middle can display different dialogs. The fixed
> windows will have buttons, edit boxes, activex controls, etc. but there will
> be no menu items, toolbar, status bar or title bar. 
> > 
> > It would be nice if I could layout the fixed Windows in the dialog editor,
> but its not a requirement as the layout is relatively simple and can be done
> at runtime.
> > 
> > As I am new to WTL so I hope someone could recommend what base classes to
> derive my fixed windows from. I assume it should be an SDI application. I
> tried copying some of the CCommandBarCtrlImpl but it keeps on complaining in
> CWindowImplBaseT< TBase, TWinTraits >::Create.
> > 
> > Also I would like some advice on eliminating the title bar.
> > 
> > Thanks,
> > Jeff
> >
> 
> 
> 
> 
> 
> [Non-text portions of this message have been removed]
>




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wtl/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/wtl/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/