I am working in Visual Studio 2005. I have multiple splitters on the screen. I have set the splitters IsFixed and I have also set fixed panel sizes. In addition to this I have locked the control. For some reason, when I switch into debug mode the splitter distance value is changing entirely on its own. These changes do not take place with any consistency, the vary in distance changed. Other components, which are also locked, are moving all on their own as well.
Anyone with similar experience? Any ideas?
The settings will stick to either mode you are in. But sometimes plugins or parts of VS does mess it up :(
I recall seeing a plugin written to save 'views', but when I tried it, it didnt work.
I couldn't tell you what is causing this. The way that the windows forms splitter works is through the Docking property. There should be no need to lock the controls. All of the controls on the form should be docked. (Including the splitter)
For example, if you want to split vertically, you have your first panel docked left. Then the splitter (Orientation set to vertical) is also docked to the left. The second panel is docked to fill. The width of the first panel (which is docked left) will determine the location of the splitter. It should not change now.
The z-order is important here for layout purposes. If you want a more detailed look of how the controls are laid on on your form, open the Document Outline. This will list the controls in a tree, and you can see where they are in the z-order.
Related
Is there some sort of shortcut key that I am missing here for swapping panels around in the form editor of vs2010?
I have numerous panels which are swapped at runtime according to an enum "toggle" value and the only way I seem to be able to move them back and forth is to make one panel smaller than another and right click it. Half the time I end up selecting some other object in the action of trying to right my panels.
I figured there must be something i'm missing here.
there are icons on the layout toolbar for this task. I pick the panel in properties and move it around with those. Way easier than right clicking and hoping for the best.
edit: although sometimes the buttons are not enabled when you need them to be. Still right clicking a resize handle adorner dot will pop up the context menu where you can then choose to move back/forward.
I still wish there was some key combo I could press. Hitting the 4px of display area that the adorner dot occupies on my screen is sort of a dexterity test of sorts and slows me down.
My application is a Windows Forms one.
I tried using the windows wallpaper, but this depends on the "Fill", "Stretch", "Fit" or "Tile" settings.
I just need the image as it is on the desktop, but including the part "under" the taskbar, because this part is visible in case of transparent taskbar.
Why I need this?
Because I have a tray application which slides from under the taskbar when opening. And I need to set a mask there, so it can't be seen sliding, until it reaches the top of the taskbar. Again, this is only a problem when the taskbar is transparent.
I am not sure if I understood your question correctly. But to me, it seems that you need the image that has created wallpaper. If it seems easier, take a look at registry entries at following location:
HKEY_CURRENT_USER\Control Panel\Desktop
This will give you the path, size, tile/no tile etc. information for the wallpaper.
There is a Win32 function called PaintDesktop you could try but unless I'm misunderstanding things you should be able to just adjust the height of your window so it is never really behind the taskbar...
Why I need this? Because I have a tray application which slides from under the taskbar when opening. And I need to set a mask there, so it can't be seen sliding, until it reaches the top of the taskbar. Again, this is only a problem when the taskbar is transparent.
The problem here is that you're starting the slide up from the bottom of the entire screen, rather than starting from the bottom of the screen's working area (i.e., the top of the taskbar). That's why you're seeing the pop-up window slide up behind a transparent taskbar.
Luckily, the solution is much simpler than obtaining the desktop background and/or doing any type of masking. It's also much faster, and it's always good that your eye candy isn't unnecessarily taxing the user's computer.
All you need to do is determine the coordinates of the screen's working area, which is defined by Windows as the area that can be used by applications, not including the taskbar and other side bars. You can obtain this information easily in WinForms by querying the Screen.PrimaryScreen.WorkingArea property. This will return a Rectangle that corresponds to the primary screen's working area. Since you know that the taskbar is always displayed on the primary screen, this is exactly what you want.
Once you have the coordinates of the primary screen's working area, start your pop-up window's slide from the bottom of that.*
This is a good lesson of why you should always include an explanation of why you want to accomplish something. There's often an even better way that you haven't thought of.
*Of course, I'm ignoring the fact that a user might not have their taskbar positioned at the bottom of the screen. You can put it on either side or even on top. It sounds to me like you haven't considered this in your question, either. If this is an app that you're writing only for yourself or for a controlled environment where you can be sure that no one has their taskbar in non-default positions, that might be OK. But if you're writing software to distribute to a wider audience, you will need to take this into account. The rcWork coordinates will be correct, regardless of where the taskbar is positioned, of course, but you will need to know whether to start the pop-up window's slide from the bottom, the left side, the right side, or the top.
This may not be the kind of question one should ask on StackOverflow, but here's a frustration that I've been trying to find a work-around for.
When using the form designer, suppose the entire form does not fit in the space allotted to the form designer, and I have a control say, down near the bottom of the form.
If I try to re-size that control, or move it using the mouse, the work area will auto-scroll to the top of the work area. This essentially pulls my control to the top of the screen. It isn't possible to scroll with the scroll wheel while "holding" a control, and even ScrollLock does nothing for me.
Is there any way to just turn the auto-scrolling off? That way I can at least work on my form without guessing numbers to type into the properties window.
Can't you just turn off autoscroll for the form?
I think it's off by default.
Form.AutoScroll = False
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.