I would like to be able to create an MDI UI layout that extends the behavior of MDI Tabbed Groups in the following way. Within a pane for a split tabbed group, I'd like to create a nested tab group with the opposite directional alignment. For instance, given a horizontally split top level, I would like to create a vertically split tab group within the first pane. This appears to necessitate a rework of the CMDIFrameWndEx and associated classes.
The Tabbed Group Layout is an appealing UI device. It's a shame it's not available in mainstream web browsers. Am I right in assuming that its best support is in the Visual C++ Feature Pack?
Here's one example, at least. Also, AvalonDock. I guess MFC remains a laggard in many respects.
Related
I use Foundation 6 and the responsive menu to change appereance menus like this :
<ul class='wrapper-list' data-responsive-menu='large-dropdown' data-disable-hover='true' data-autoclose='false' data-click-open='true'>
When screen is large I have a dropdown but when I resize screen to small/ medium menu stay in dropdown and this is a big problem for me.
If I load my page in small size my list is visible and I don't have dropdown, but if switch with large screen and small again menu disappear like dropdown behavior...
How can I "reset" menu with initial appearance (html basic) with no interaction of js when screen is small ?
Do you know if there is a rule to say large-dropdown-only like visibility class ?
Thanks a lot and sorry for this horrible english...
Foundation is mobile first, so you need to set dropdown class for small screen. It works similar to column's clases. If you set class only for small, all screens will inherit.
Prefixes medium and large are required.
Prefix small is not required, so any menu specific class without prefix will be considered as class for small.
If you have two classes without prefix, the last one of that two will be used for small screen.
Also if you have two classes with same prefix, the last one of that two will be used for that screen size.
<ul class"dropdown medium-accordion large-drilldown menu"></ul>
I need to implement a threaded view of sorts in an old VB6 app. It should look similar to this:
So, it's like a TreeView of sorts but there are buttons on the right (for each row) that could be pressed. The view does not need to collapse - it always stays in the expanded mode. The users should be able to respond to each node (via the comment button on the far right). And, of course, users should be able to scroll through the entries.
What are some of the ways I could implement this? I am open to 3rd party controls, paid or not.
VSFlexGrid has an outline mode. You can set the indent per row via the RowOutlineLevel property. It supports word wrap, images, etc within its cells/columns so you should be able to get pretty close to what you want. It also supports owner-drawn which lets you fully customize the cell painting (for example, to get those rounded corners).
I'm sure there are other controls out there as well...
I'm using MFC (yes must be MFC and no I can't interop with .Net) to create a CFrameWnd.
My goal is to create a CFrameWnd containing a CFormView which is based on a Dialog Template that resembles something like:
I have got the frame and view to display, and I have an Edit control on there. Now what I want is to have a CToolbar aligned to the top of the Edit Text control but not docked to the top frame.
Ideally I would like to have a child frame/view that I can dynamically add in place of the Statement Group. That way I could just dock the toolbar as normal.
The thing that I find odd is that I could easily achieve this if I had a splitter in there by using the CreateView function. I really don't want to have a splitter and feel there ought to be another way.
In summary, these are the question I need help with:
Q1 - How can I have a CFrameWnd within a CView (like what CSplitter::CreateView does)?
Q2 - How can I position a toolbar within a CView without docking or floating it within another frame (I'm more than willing to resize, position it manually if only I knew how)?
Now I really appreciate how easy things are in .Net.
I wouldn't recommend sticking a CFrameWnd within a CView. You'll be fighting MFC all the way, basically living in a world of ASSERTs as the internal functionality such as message routing assumes that Frames don't live in views.
Instead just use a CWnd instead of the CFrameWnd and in the 'Create' method manually create the toolbar and the edit ctrl and size and position them yourself (create a AdjustLayout method that uses CMFCToolbar::CalcFixedLayout to adjust the position of your other components).
A great example of this is in the Visual Studio sample app PropertiesViewBar.cpp:
http://msdn.microsoft.com/en-us/library/bb983983(v=vs.90).aspx
Note: You might need to override OnCmdMsg to extend the message routing to the internal controls.
VS2008 seems to have a new feature that allows one to split a website into the source code and design aspects on the same page. This feature seems great, however it defaults to having the design part on the bottom half of the screen and the code part on the top half.
Unfortunately, my brain doesn't work this way and it ends up being more of a hassle than to just continue switching back and forth when needed like I've done in the past.
Is there a way to swap them so that the design part is on the top and the code part on the bottom? Most other tools in VS are drag and droppable, so I can't see why not, but I'm not finding the setting anywhere. I did a quick google search and found a way to make the split vertical, but thats not what I'm looking for. I'm just looking for the same horizontal split with the design part on top.
Thanks
Here's an alternative approach that may help. If it's a traditional .aspx page (one that has a codebehind), you can open both documents simultaneously. Then right click one in the tab area at the top and select New Horizontal Tab Group. You can manipulate it so that the design window is on top of the code window.
I would be very surprised if this possible, since I have never seen a window configuration that changes the vertical alignment of the Objects and Events drop-down-lists.
I could be wrong, though.
It does seem rather strange - in the xaml designer you can split the screen whichever way you want as there is a button to switch the position of the panes. The options for the html designer only seem to allow a vertical or horizontal split though, there isn't anything in there specifying whether to have code or design at the top, it does seem a little backwards as I imagine most people find it more natural to have the visual designer at the top with the code below.
I am thinking of implementing a ribbon GUI in one of my apps and of course want to adhere to the MS Guidelines so it feels like a normal ribbon, etc. But I'm trying to figure out how to solve a specific problem in dynamically changing the ribbon.
I'm creating a concept game editor, please no question on why a ribbon as this is purely a concept idea, but the application will have many editors (2D, 3D, Code, etc) and for each one the GUI should adapt and display relevant controls i.e. in the 2D editor maybe a paintbrush, on the 3D many pan and rotate tools.
Given the ribbon guidelines it makes sense to the Home menu to contain the most common tools, but only for the type of object being edited (rotate makes no sense for 2D or Code!).
I initially thought it could have one window per editor but this makes a real mess and I'd rather have lots of tabbed editors so you can flick through them fast like in eclipse etc. Also all editors save back into one file so it makes sense to have one application window to keep this metaphor for the user.
I was thinking I could dynamically change the ribbon tabs depending on what type of editor the user had open (tabs may appear/disappear, content on the Home tab etc would change) but then this breaks the MS guidelines of:
"Controls displayed in a group MUST NOT change as a result of selection. If a control is not active, then the control MUST be grayed out, rather than removed from the group"
"The tab selected on the Ribbon MUST NOT automatically switch as a result of user selections made in the 177 document (except as noted in the Contextual Tabs section)."
I understand the reasoning behind the guidelines but im not really sure how to get the ribbon to feel right in this situation:
Change the content of the tabs
depending on editor type (goes
against the guidelines)
Have a tab
per editor type (but what if i end up
with 15 editor types!)
Have a very
generic ribbon and move specific
editor operations to a side bar or
something (not the best GUI design)
Use contextual tabs for each type of
editor (better solution but means you
always have one contextual tab open!)
Any other ideas/solutions would be greatly appreciated as I must use a ribbon and must use it for this type of application!
If you are providing a tab that is editor-specific, I suppose you could lay it out in the way that is best for that particular editor. That means that controls are going to move around occasionally, if you use the same tab for the other editors. It doesn't seem practical to gray out the controls that don't apply to any particular editor, if it's going to cause a lot of clutter.
On the other hand, graying out controls does have the benefit of keeping each control in exactly the same physical place on the tab. Do not underestimate the power of this. There's nothing more aggravating than expecting a control one place, and having it suddenly move someplace else (or disappear altogether). The graying out is a clear indication that the grayed control does not apply in this context.
So depending on how different the controls are for each editor, you will have to decide which approach is less disruptive: to gray out the unneeded controls, or to provide a fresh layout for each editor.
It doesn't seem workable to open a tab for every editor that's open, since there will be many tabs that are useless when the user is in a specific editor.
If possible, enlist the help of some volunteers or beta testers, and do some paper prototyping with them to see which approach resonates better with them.
I'm facing the same design problem. One idea is to use different frame for each editor and a different specialized ribbon in it. Because there's little point in a big ribbon with 10 tabs full of disabled commands.
P.S. I'm investigating another idea - to use certain tabs clicks for triggering different editor modes. (I'm designing a house drafting program.) In example:
Clicking "Home" tab switches to the
plan editor to the edit the house
from "top" view;
Clicking "Wall"
tab switches to the wall editor
where you can edit the wall shape
and featues.
Clicking on other tabs
may not change the current editor.
They can show up other non-modal
commands that are related to the
whole document (or something else),
not about the current editor mode
itself.