In a WPF window I implemented a component that gives an indication of all active errors in the system.
The component is located in the task bar and
If one hovers over the component a tool-tip is shown with summary info
If one clicks on the control, a panel is the activated that is showing a detailed list.
In the application we also use wizards implemented as modal windows.
Now, here's my problem: if a new event occurs in the system during an active wizard, the component in the task bar is updated however I cannot use the hover event to see a summary. Both events (hover and click) are not usable due to the modal dialog that hides the parents message loop.
Is their a way (or what's the best solution/suggestion) to have at least the hover message active while the modal wizard is present.
Thanks.
They don't call it "modal" for nothin' :-)
Humor aside, depending on your exact scenario, here's two options and a third option that's a bit more involved and you probably don't need it but it can handle a wider range of scenarios:
Option 1. It sounds like you have a normal app that does not show its MainWindow and is using only its taskbar presence. If this is the case then you don't need a dialog at all, simply use the MainWindow itself as the "dialog".
Option 2. If you are already using the MainWindow visibly then use a pseudo-modal approach whereby you don't actually use a dialog but all other controls except the control acting as your "dialog" control are hidden/collapsed.
Option 3. Use two separate processes. Basically, this is two separate apps - one is your taskbar component and the other is your main app. Use IPC to link the two - e.g. I have used a Windows pipe for such a thing and it works fine.
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 am doing a UI automation for a WPF application using the Microsoft UI Automation library and it works well.
However my app has four screens in a TabControl. Even when I click the tab item through code its child control tree isnt populated. The only control I can see is the "thumb" Control. Same happens when I see the control tree with UISpy.
However if the window is clicked then all the controls appear. As a Workaround I am simulating a mouseclick through code and it works. I wanted to know if there is some better way of doing it.
I ran into a problem similar to this. What was happening was some data was being retrieved on threads and the controls were not generated at the point automation peers were generated. I would suggest if you have access to the code base for the application you are attempting to automate looking into whether threading is being used. In my specific case it was because BeginInvokes were used to retrieve the data, I switched them to Invokes and it worked fine.
Also from what I could tell the reason the controls were being show on mouse over was because the tool tip generated a popup and caused the automation peers to be updated.
Why don't you click the control using mouse events if that is what works.
(Now, if you still are having that problem..)
How to simulate Mouse Click in C#?
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.
For instance, I have an application that has a main window and then child windows inside of it.
http://screenshots.rd.to/sn/e3hek/sapienfullwindow.png
http://screenshots.rd.to/sn/e3hek/appscreen8.png
What i need is to grab each individual child window of that application, and display them as tabs in my application, or on a panel's handle.
I already have code to kidnap the application and put it into mine, and it works great.
MDI support is already present in the C#. So the first screenshot is using the MDI option.
The second screenshot is using tabbed windows. Now you have two options:
Use this opensource library DockPanelSuite which will let you have tabs in your application. something similar to visual studio interface. You can create forms and then tab it based on your needs. You can even dock them anywhere in the parent form by drag and drop. Just like in visual studio.
The second option is to create a form with tab control covering the whole windows. There you create tabs using the resource editor and hide/show based on the forms you want to display to the end user.
In my opinion, use the first option which gives you lot more customization. Also if you use the dockpanel, you can switch between the views shown in your first screenshot and second one. So user has better control as to how he wants to view. Dockpanel is free to use even in commerical apps and comes with source code. So you can either use the dll or directly incorporate the code in your application.