I was trying to create an extended title bar in my program, I got the basic functionality, such as the extension from the glass frame, the actual moving of the window on click, but I still don't know where to start when mimicking the context menu that appears when right clicking the Windows title bar.
Of course, I could probably throw down some self-made context menu that looks exactly the same, but that would be quite cheaty, inconsistent, and not native.
Here's the code I am currently using:
private void Navbar_MouseDown(object sender, MouseButtonEventArgs e)
{
if (e.ChangedButton == MouseButton.Left)
{
while (e.ButtonState == MouseButtonState.Pressed)
{
this.DragMove();
}
}
}
private void Navbar_MouseUp(object sender, MouseButtonEventArgs e)
{
if (e.ChangedButton == MouseButton.Right)
{
// open the title bar context menu
}
}
Any help would be appreciated!
ALSO, I didn't try anything YET, because I don't know where to start, and everywhere I looked for, everything was talking about modifying the context menu, not even describing how to display it programmatically.
I even found a Stack Overflow post that asked for almost the same thing, but instead talking about modifying it, which was not what I wanted. One of it's tags were wpf but it got closed as a duplicate to a post asking how to do that in WinForms, with another answer talking about WinForms, even though the question had the wpf tag.
Stack Overflow's automatic "Do any of these posts answer your question?" tool gave results that were completely unrelated to my question, and brings us back to square one.
You could use the WindowChrome.CaptionHeight property to specify the area at the top of your custom window that enables the system behaviors typically associated with the title bar, such as for example displaying the ContextMenu.
Related
I am attempting to create my own context menu that shows when Word is in a custom 'mode'. To do this I want to disable all default context menus in favour of mine. This works perfectly when right-clicking text but not when right-clicking images or text boxes (seems to be objects in general). It looks like the event's Cancel parameter gets ignored when images are right-clicked, therefore it doesn't stop Word's context menu from showing.
Am I doing something wrong, or is this a bug in Word?
Does anyone have a solution for globally adding context menu items and hiding the rest?
Alternatives to my goal might also be the solution.
I have tried to use ribbon.xml but there are many different context menus with many different buttons, galleries etc which I would have to actively hide. Plus, I would have to duplicate a lot of XML to add my buttons to all these menus. In this pursuit, I have found the documentation for listing these context menu items lacking a complete list which has left me hunting for button idMso's. Also, if Microsoft were to add a new item, I would then have to release an update to actively remove the new item. The whole ribbon.xml way of dealing with context menus is a very difficult way of achieving what should be a simple request (in my opinion).
public partial class ThisAddIn
{
internal bool CustomContextMenuMode = true;
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
ThisAddIn.WordApplication.WindowBeforeRightClick += new Word.ApplicationEvents4_WindowBeforeRightClickEventHandler(Application_WindowBeforeRightClick);
}
private static void Application_WindowBeforeRightClick(Word.Selection Sel, ref bool Cancel)
{
if (CustomContextMenuMode == true)
{
MessageBox.Show("Context menu shows here!");
Cancel = true;
return;
}
Cancel = false;
}
}
If you right-click text (with or without a selection range), a table, or many other things, you will see that the message box shows. And when dismissed, the Cancel parameter prevents the default context menu from showing.
However, when an image is right-clicked, it shows the message box (like before) but when dismissed it still shows Word's image context menu.
Here is my Word version:
Office 365 Business,
Word version 1903 (build 11425.20204) or v16.0.11425.20200
Thank you in advance!
I have a WPF .NET 4.6 application running on a Windows 8.1 tablet and for the last few days I've been struggling to make my app touch friendly to make it work as expected. My main problems are focus related, these affect several controls in my app. for example:
Textboxes: sometimes requires a double or triple touch in order to get input focus, they do enter a mouse over state but the caret isn't there;
ComboBoxes: takes a couple of touches in order to open it, and once touching an item in order to select it the combo stays open with the newly selected item highlighted;
Buttons: takes a couple of clicks to run the connected command and stay in mouse over state;
Keyboard support
There are a couple of approaches I tried while searching for a solution that each has it's own downsides:
Removing the tablet support for the entire application (taken from here). this one solves most of the focus problems mentioned above but makes scrolling (and I guess some other Tablet related functionality that I haven't found yet) unusable.
Explicitly activating the keyboard when required (Example here). Focus problem remains, scrolling works as expected
I also tried to remove all styles and tested everything on 2 different tablets from different manufacturers but without success
Recently Microsoft announced that "Touch is better" But I couldn't find any official documentation about the best way to approach this subject.
Any suggestion on how to make my application work better with touch would be a big help.
I was able to remove mouse over state by using following behavior:
public class TouchDeviceMouseOverUIElementFixBehavior : Behavior<UIElement>
{
protected override void OnAttached()
{
AssociatedObject.StylusUp += AssociatedObject_StylusUp;
}
protected override void OnDetaching()
{
AssociatedObject.StylusUp -= AssociatedObject_StylusUp;
}
private void AssociatedObject_StylusUp(object sender, StylusEventArgs e)
{
var control = sender as FrameworkElement;
if (control != null)
{
if (!VisualStateManager.GoToElementState(control, "Normal", true))
{
VisualStateManager.GoToState(control, "Normal", true);
}
}
}
}
App I am trying to create in WPF/C# has quite a few buttons in a layout with a "TV screen" type panel above (its actually an FMS emulator for commercial aircraft). Many of the buttons change the layout, which are numerous TEXTBOXs on the tv screen. My question is: is there a provision to encapsulate the layouts in different classes/files and load them into the "tv screen" at the selection of the various buttons? In other words, user hits the Flight Plan button and the layout of the 355x355 box (screen) above loads the XAML "flight_plan" layout/file/class. Each layout has different TEXTBOX sizes & locations and there are in excess of 30 different "pages", which would make encapsulating them desirable.
I am very new to WPF and c#, but have written win apps in c++ all the way back to Turbo C & OWL. I also may be trying to do something that isn't possible due to working lately in Android/Java and am confusing capabilities.
Thanks in advance.
Edit
Thanks to #adityaswami89 and everyone else who got me on the right track, I have found the solution. I added the pages via a new "WPF Page" in VS2012. Then changed the "screen" to a navigation frame and it was truly simple from there. Below is the simple project I created to test it.
public partial class MainWindow : Window
{
NavRad navrad = new NavRad();
FPlan fplan = new FPlan();
public MainWindow() {..}
private void Frame_Navigated_1(object sender, NavigationEventArgs e) {..}
private void Button_Click_1(object sender, RoutedEventArgs e)
{
Screen_Frame.Navigate(fplan);
}
private void Button_Click_2(object sender, RoutedEventArgs e)
{
Screen_Frame.Navigate(navrad);
}
You can also use the concept of Frames for the intended functionality , if that can be an option you are looking.
You can refer the below link for the same.
http://msdn.microsoft.com/en-us/library/ms750478.aspx#Frame_in_Standalone_Applications
You can abstract the different UI Layout Sets within different User Controls and load them according your UI logic. One way to do this is using an MVVM framework, for example, Caliburn Micro makes this a pretty simple task as doing:
ActivateItem(UILayoutViewModel);
And this call can be called from any method.
See more of Caliburn Screens and Composition at official source.
I'm refactoring a body of code, looking through it all, line by line.
I came across an event handler:
private void mnuUpdate_Click(object sender, EventArgs e)
...and, not recognizing which menu item called this (the menu item names do not always match their labels, or even come close), was curious.
The main menu on the form has no such menu item among its children.
I r-clicked the event handler, selected "Find Usages*" and was led here:
this.mnuUpdate.Text = "Update";
this.mnuUpdate.Click += new System.EventHandler(this.mnuUpdate_Click);
(This is an antedeluvial app that predates .NET's partial class goodness, so this is in the same file)
On the form in the designer, when I select "mnuUpdate" from the properties page combobox, the mainMenu on the form disappears altogether.
How can I track down this fugitive menu item? There is no popupMenu or contextMenu on the form, just the mainMenu control...???
The only other usage is:
if (ResetConnectionFetchForm)
mnuUpdate_Click(sender, e);
Is it possible that this is simply a phantom menu item that should be converted into a "regular old" method?
UPDATE
As the most intelligent George used to say, "Curiouser and Curiouser." Now I find this:
public void btnCancel_Click(object sender, EventArgs e)
...and though it is called from seven places in the code, there is no btnCancel on the form...It is a "fake" button click event. Oh my Lanta!!!
So, I replaced it with a parameterless private method with the exact same code (it didn't use either sender or event args).
If the cat who wrote this cockamamie glob of fruitcake-battered spaghetti was deliberately trying to drive the next cat (me) crazy, it's working pretty well, and would make a good Poe-style story or Hitchcock-style flick.
...I see...Dead Code!!!
Okay, mystery solved. mnuUpdate is dynamically added (conditionally) to mnuSetup (which is a top level menu item with the Text property "Fetch") like so:
if (!mnuSetup.MenuItems.Contains(mnuUpdate))
{
mnuSetup.MenuItems.Add(mnuUpdate);
UpdateMenuItemSelectable = true;
}
I reckon selecting mnuUpdate from the combobox in the form's Properties page is because there is no visual representation to show at that point.
Selecting "mnuSetup" highlights the "Fetch" menu item, but selecting "mnuUpdate" causes it all to scurry away faster than cockroaches from the light.
So the bizarre thing about it now is: why is the menu item not dynamically created as necessary, instead of being explicitly created and then dynamically added; seems like a strange way for a cat to skin a cat.
I'd suggest you turn it into "regular old menu" so someone else doesn't waste time figuring it out.
Me - I would have thought it obsolete code because it doesn't have a Handles clause.
You can use .Visible and .Enabled to control what the user sees.
I have a C# Winforms app that uses the HelpProvider class.
Whenever i press F1 to bring up help, the help window will always be on top of my application, I cannot bring my application UI to the foreground. I can still interact with my UI, but the help window will remain on top.
Is this by design of HelpProvider? Or am I missing something?
There is a solution to this issue, a bit dirty, but it works.
The thing is, the help window opened by HelpProvider is always on top of its parent window control, which is determined by Control instance in first parameter of Help.ShowHelp. Even if you specify null there, the main application form is still used as parent window.
To avoid this, one can create a dummy form, which will be used as a help parent form. This form will be never shown, but still, help window will be “on top” of it, effectively being NOT on top of all other application windows.
public static class AppHelp
{
private static Form mFrmDummyHost = new Form();
public static void ShowChm()
{
Help.ShowHelp(mFrmDummyHost, "my_help.chm");
}
}
Of course, all other Help.ShowHelp overloads can be called this way as well.
Hope this helps people like me, searching for answers to never-getting-old questions ;)
It is indeed by design, and its something that i did not realise. I have just recompiled my final year project and confirmed it. I have read up about it and basically the help file is set to TopMost=True every time the form is clicked. This means even if you code your form to be TopMost, as soon as you click the help file it will go back on top again.
I do believe if you use start process, it should get around the issue at the loss of some customisability the help provider gives.
private void textBox1_KeyDown(object sender,
System.Windows.Forms.KeyEventArgs e)
{
if(e.KeyCode ==Keys.F1)
{
System.Diagnostics.Process.Start(#"C:\WINDOWS\Help\mspaint.chm");
}
}
Hope it helps