When I create a new window using .Show(), it shows the new window, however my icons are grouped like below:
I don't want that. I want the icons to be separate because I want my users to easily open the window that they want instead of having to click it, view the list of open windows, then choosing which one they want every time. I don't want to use .ShowDialog() because I need the users to be able to focus on either window no matter the state of the other. Meaning, both windows will need to be open and the user will need to be able to interact with each of those windows regardless of if the other window is open or minimized.
I've tried setting the parent, but I don't think I'm taking the right approach. I've never worked with icons before, so excuse my lack of knowledge.
var w = new Window();
w.Owner = Window.GetWindow(this);
w.Show();
I will be changing the icon of the second window that gets opened so that the user knows which one to click on based on what they want. I'm just trying to get around the grouping that seems to be the default.
(If i'm correct) In Windows it's possible to assign a seperate AppUserModelID to your shortcut icon to prevent the default grouping of icons, this is the page explaining how to define and assign a seperate AppUserModelID. I would suggest reading the provided source thouroughly.
Related
So I'm sure there's an easy way to do this but I don't know the exact terminology for what I'm wanting.
Essentially in my C# xaml uwp app I have a couple objects that need to have details added to them, kind of like file properties. I have a button that I would like to open up another window (still part of the app), just to enter in the properties. I just don't know the terminology to look up what this window would be called or find documentation for it. So the exact same as when you're in a file browser and you open the properties of a file; it opens in a little extra window that you can drag around.
I don't want to be able to use the main window while the properties window is open, and of course they need to be able to transfer data between one another.
In my previous apps I've simply made a grid that appears over everything else in the middle of the app and shaded the outer area. A workaround as I didn't know how to do this.
Can anyone help me out?
Maybe you can use Dialog refer to https://learn.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/dialogs-and-flyouts/dialogs.
Dialog controls are modal UI overlays that provide contextual app information. They block interactions with the app window until being explicitly dismissed. They often request some kind of action from the user.
I'm developing a bunch of user controls which do different things - like a maintenance screen, enquiry screen, report screen that sort of thing. Each screen has a dedicated purpose and a single user control holds all the functionality for the one screen.
I'm using avalondock and can place these user controls into LayoutDocuments. This creates a separate tab for each screen/user control. I've got a menu system setup so users can choose which screens they need access to. For each new screen I create a new LayoutDocument, add the appropriate control to it, then add the LayoutDocument to the Docking panel's children.
This is all working fine.
Avalon dock also has the feature of being able to drag out the layout document and make it float - you can also dock it somewhere else in the app if you wish.
I'd like to take this concept one step further: Being able to say right click on a layout document and choose "Make external window" (i'll work out the exact wording later). The effect of this action would be to create a new application with it's own icon in the task bar; being able to alt-tab between it and other apps;
Kind of like when you're in say Excel editing a document and you then open up a second instance of excel. In Windows 7 you get two excel icons in the task bar (one behind the other), and you can alt-tab between them.
This is nearly the behaviour that i'm after. However the second app isn't a full blown copy of the first; it has only the one user control that the user selected.
This is where i'm stuck and would like a bit of guidance.
I'm thinking that i'll probably need some kind of shell app where I can pass in the user control that I want. The shell would act as a window with title, X, minimising etc; the user control would then be the sole content of that shell. Use process.start to create new process and launch ?
Ideally i'd be able to pass in the same control in the same state as the user is currently viewing - so if for example they are part way through editing some customer record in a maintenance screen, then choose the "external window" option, that same customer record would appear in the new window.
Has anyone done something similar or offer advice if i'm on the right track ?
I think I know how to create a shell app but not sure on passing a user control to it dynamically. I'd like to avoid creating different shell apps for each user control.
No need to start a new process for that scenario.
Just create a new Window add your UserControl at runtime and remove the UserControl from the DockingManager. Make sure the Window has ShowInTaskbar set if you want it to show up there.
To get the command to undock the UserControl as a seperate Window you just have to restyle the ContextMenu to incorporate your command (take a look at the VS2010 theme and how the ContextMenu is styled there VS2010 theme.xaml).
I'm currently designing an MDI application (a custom CRM) in .net 4.0 and i'm starting to dislike the whole interface simply because there's no real way to track which windows are open or closed and it'll probably lead to a very confusing interface.
What is the best way to avoid this?
- Should i implement a taskbar to track every open mdi child?
- Should i use dialogs instead to prevent multi-tasking?
- Is there any way to change the size of a minimized window on a mdi container (why are they so small, you can't even read the full form title that way...)
Sorry for so many questions, thanks in advance.
MDI has its uses, but as you've found can easily lead to a cluttered, hard-to-use interface. The current in-vogue way of dealing with this is to add a tab control (as in any web browser, or most text editors/IDEs) to allow switching between open views. This is close to a task bar I guess.
Other options are controls like the Outlook bar (the big view chooser down the left-hand side of Outlook) or possibly just a simple list box with the currently open views.
Alternatively, consider how often you really want multiple windows available and whether most of them are "tool windows". If so, perhaps look at using docking windows for these tool windows, and a Single Document interface for the rest of the app. All depends on what you're actually doing!
The MDI windowing management already has the built-in to track open windows by way of the menu. The ToolStripMenu has an MdiWindowListItem that you can set to a reference of the menu item that will contain the list of open windows. If the menu is attached to the MDI parent window, child windows automatically populate the menu item.
One of the objectives of MDI is to allow multitasking. If that's not what you want, use a different design.
As far as changing the size of the minimized windows, apparently it's not possible using the standard Windows interface. See more info here: Is it possible to change size of minimized window in MDI C# Winforms. But you could remove the standard Minimize button, add your own, and do what you want with the windows in a Normal state.
Our WPF application in the current design opens new windows for list screen.We don't have restrictions on the number of windows you open etc.We are using a ribbon control and well it has tab support.Which is better a new window or a tab? (With windows 7 having a better group of window management etc) Should I go in for tab or leave it as window. I can't make the detail screen tab since well the user click of a item in the grid to select and edit.Any valid suggestions? Thanks in advance.
Tabs in a Ribbon shouldn't change the view. The Ribbon is an enhanced toolbar, not a view changer.
If your using the MS Ribbon via OfficeUI, then there is a stipulation in the design guidelines that the view should never change the appearance of the ribbon (apart from loading context tabs) and that they ribbon should never wholesale change the view.
In regards to your question, do you mean that you have list/grid and you want a view to be able to change the data in the row. Eg. they double click a row, a view appears that gives them the ability to edit that row?
The right way is to ask your users what they like more. If you can't ask users, ask yourself - what you find more convenient - to open\close windows or switch between tabs. I wouldn't rely on win7 task bar as it's grouping behavior can be disabled or users may use another OS. Also I would suggest to check Microsoft guidelines for using ribbon.
Do you need to see more than one pane's content at once? Windows allow this, but tabs do not.
Tabs make management of the various windows easier at the expense of some flexibility.
Are your users likely to be running on multiple windows?
It is really hard to give a confident answer to you on this one without knowing more about your application and your user's requirements.
Windows 7 displays multiple previews on grouped windows of the application, however in case of tab, like IE, you will have to write quite a good custom code to show your tabs in preview of Windows 7 taskbar, which in case of Multiple Windows, it will be done automatically.
Not only that, Windows 7 also lets you put seven toolbar buttons on the preview windows, very few people knows about it because no application currently does it.
For tabs you will need to do extra programming to support multi window preview.
So its better to stay with multi window solution for now.
However in case of IE, if you try to use Windows 7 taskbar, the tabs dont align themselves in correct order of what is displayed in preview, it could be bug, but yes there might be certain limitations because when user chooses the tab to preview you will not be able to show them preview unless you make it active and thats why its little bad.
I recommend playing with Mozilla Firefox and Google Chrome if you want to see tabs at their finest.
Notice that tabs can be teared out into a separate window and windows can be docked as tabs.
I'm searching a C# component or code snipped that does something like that:
I want to inform new users about the most important program functions if he opens a new window for example.
It should be a box showing text (formated if possible) that is of course not modal and has some mechanism to 'go out of the way' if the user enters the textbox area. So that he can access what's underneath it. Alternativly the window could also stick to the border of the window, but there needs to be a way that this also works if the window is maximized.
So I want to present him with a short introduction of what he can do in every corner of my app most painlessly.
Thank you!
I use a "bar" at the top of every window to display some information about the current window/dialog.
Use tooltips. They can be programmatically controlled, and you can have them appear at will. You'll need to add the functionality to your app to keep track of what tooltips have been shown to the user already.
You can add a "balloon" style by setting the IsBalloon property to true.
You can also replace them with smaller descriptions for when the user wants to hover over the control and have them displayed again.
I'm already using tooltips heavily. However, they aren't very practical when displaying bigger amounts of data and they are bound to specific user actions.
Have you considered having a contextual menu for each form / page which contains links to Adobe Captivate style presentations for each available task? That way the user can investigate an example of how to achieve a task relating to what they are trying to achieve from within the application / site.
This approach would require a good deal of maintenance and management if your code changes regularly but coordinating it with a training department can provide rich help features in your application.
See http://www.adobe.com/products/captivate/ for more information.