|
The target Form's OnActivated event handler is called.
|
|
|
|
|
I would like to be able to add to the View menu in Visual Studio. I am developing a add-in and want to be able to display my own ToolWindow as needed. I am able to add my menu to the top level menu with the code below, but as stated I want this menu Item added below the View menu. I don't want the menu item displayed until the add-in is loaded. The Wizard generated code shows how to add to the Tools menu, but when I try to do the same with the View menu it does not work (CommandBar commandBar = (CommandBar)commandBars["View"];)
// Add to the View menu
object []contextGUIDS = new object[] { };
Command viewCommand = commands.AddNamedCommand(addInInstance,
"ViewAutoReplace", "Auto Replace View",
"View the Auto Replace Tool Window",
true, 53, ref contextGUIDS,
(int)vsCommandStatus.vsCommandStatusSupported+
(int)vsCommandStatus.vsCommandStatusEnabled);
CommandBar barView = commandBars["MenuBar"];
CommandBarControl barControl =
viewCommand.AddControl(barView, 2);
I have tried commandBars["MenuBar.View"] and ["MenuBar.&View"] with no success.
|
|
|
|
|
Might help[^].
If you are lucky, you are only facing a proper use of MSO, not a VS.NET extension limitation (which I have faced a couple months ago about the claimed-to-be-programmable Resource view window).
|
|
|
|
|
looking for something like a code guidline....
i.e. that a TextBox should have the prefix: txt
TextBox --> txt i.e. txtCustomer
Label --> lbl i.e. lblCustomer
String --> str i.e. strCustomer
bool --> boo i.e. booIsValide
is something like that anywhere available?
gicio
|
|
|
|
|
|
|
I no longer use prefixes for tpyes (str, int, lng, etc...) but I do still prefix controls (txt, cmd, etc...). This helps me see the differences between a control reference and a variable.
The only prefixes I use on vars are scope level. I use m_ for module level vars.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
|
|
|
|
|
Here is one for the experts. I have searched high and low for a solution, and only found one posting that said:
Sorry, this is a known issue with Owner Drawn Context Menus on Notify Icons. We are examining possible fixes for a future release.
This reply was posted by The Windows Forms Team at Microsoft on 12/12/2002.
I know my ContextMenu works, because it displays properly when I assign the ContextMenu object to the main form. When it is assigned to NotifyIcon's ContextMenu object, a blank menu is drawn.
<br />
<br />
XPMenuItem mnuShow = new XPMenuItem( ... );<br />
XPMenuItem mnuPreferences = new XPMenuItem( ... );<br />
XPMenuItem mnuSeperator = new XPMenuItem("-");<br />
XPMenuItem mnuExit = new XPMenuItem( ... );<br />
<br />
contextMenu.MenuItems.Add(mnuShow);<br />
contextMenu.MenuItems.Add(mnuPreferences);<br />
contextMenu.MenuItems.Add(mnuSeperator);<br />
contextMenu.MenuItems.Add(mnuExit);<br />
<br />
notifyIcon.ContextMenu = contextMenu;
this.ContextMenu = contextMenu;
<br />
Does anyone have any idea how to correct this or if a solution from Microsoft has been released?
Thanks for helping out the newbie,
Ethan
-------------------------------------------
One good thing about repeating your mistakes is that you know when to cringe.
|
|
|
|
|
Here is the code snippet again. Sorry the code font was so small :
<br />
XPMenuItem mnuShow = new XPMenuItem( ... );<br />
XPMenuItem mnuPreferences = new XPMenuItem( ... );<br />
XPMenuItem mnuSeperator = new XPMenuItem("-");<br />
XPMenuItem mnuExit = new XPMenuItem( ... );<br />
<br />
contextMenu.MenuItems.Add(mnuShow);<br />
contextMenu.MenuItems.Add(mnuPreferences);<br />
contextMenu.MenuItems.Add(mnuSeperator);<br />
contextMenu.MenuItems.Add(mnuExit);<br />
<br />
notifyIcon.ContextMenu = contextMenu;
this.ContextMenu = contextMenu;
-------------------------------------------
One good thing about repeating your mistakes is that you know when to cringe.
|
|
|
|
|
The NotifyIcon class has a WndProc method implementation which looks much like any standard WIN32 procedure. Reproduced here :
private void WndProc(ref System.Windows.Forms.Message msg) {
int local0;
local0 = msg.Msg;
if (local0 == 273)
goto i3;
if (local0 != 2048)
goto i4;
local0 = msg.LParam;
switch (local0 - 512) {
case 3:
this.WmMouseDown(msg, 1048576, 2);
return;
break;
case 1:
this.WmMouseDown(msg, 1048576, 1);
return;
break;
case 2:
this.WmMouseUp(msg, 1048576);
return;
break;
case 9:
this.WmMouseDown(msg, 4194304, 2);
return;
break;
case 7:
this.WmMouseDown(msg, 4194304, 1);
return;
break;
case 8:
this.WmMouseUp(msg, 4194304);
return;
break;
case 0:
this.WmMouseMove(msg);
return;
break;
case 6:
this.WmMouseDown(msg, 2097152, 2);
return;
break;
case 4:
this.WmMouseDown(msg, 2097152, 1);
return;
break;
case 5:
if (this.contextMenu != null)
this.ShowContextMenu();
this.WmMouseUp(msg, 2097152);
return;
i3: if (IntPtr.Zero == msg.LParam) {
if (!(Command.DispatchID(
msg.WParam & 65535)))
goto i5;
return;
}
this.window.DefWndProc(msg);
return;
i4: if (msg.Msg == NotifyIcon.WM_TASKBARCREATED)
this.WmTaskbarCreated(msg);
this.window.DefWndProc(msg);
return;
i5: return;
break;
default:
return;
}
}
Anytime it receives the windows message identified by 512+5 (WM_RBUTTONUP), it calls ShowContextMenu(), whose implementation is :
private void ShowContextMenu() {
POINT local0;
if (this.contextMenu != null) {
local0 = new POINT();
UnsafeNativeMethods.GetCursorPos(local0);
UnsafeNativeMethods.SetForegroundWindow(this.window.Handle);
this.contextMenu.OnPopup(EventArgs.Empty);
SafeNativeMethods.TrackPopupMenuEx(this.contextMenu.Handle, 64,
local0.x, local0.y, this.window.Handle, null);
UnsafeNativeMethods.PostMessage(
this.window.Handle, 0, IntPtr.Zero, IntPtr.Zero);
}
}
I guess you've figured out by now that, to attach an owner drawn menu, you just need to override the ShowContextMenu() method implementation.
Good luck!
|
|
|
|
|
in order to split a string into an array of lines, I do the following:
myString.split(new char[] { '\r', '\n'});
The problem is that I end up with empty lines. I would like to know if it is possible to avoid that, not having lines with \r or \n at the end, in one similar call. Also, if the user enters empty lines, i would like to preserve them.
|
|
|
|
|
Regex.Split(myString, Environment.NewLine);
Should do it, I think.
Or, probably more efficiently:
myString.Replace(Environment.NewLine, "\n").Split('\n');
Paul
Pleasently caving in, I come undone - Queens of the Stone Age, No One Knows
|
|
|
|
|
Paul Riley wrote:
myString.Replace(Environment.NewLine, "\n").Split('\n');
worked perfectly. tx
|
|
|
|
|
I'm having real trouble creating a Render Context from a C# user-control or a Graphics object. It should be just as easy as filling in a pixel format descriptor, choosing a simliar format, and setting it. However, although the pixel format gets chosen and set fine, when I call wglCreateContext it always fails, with the Invalid Pixel Format error.
Can anyone help??
Dave Kerr
focus_business@hotmail.com
www.focus.programmersnet.com
|
|
|
|
|
Could someone tell me how to get the short filename from a long filename using C#?
Thanks,
Matt
|
|
|
|
|
Use the GetShortPathName API:
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
private static extern int GetShortPathName(
[MarshalAs(UnmanagedType.LPTStr)]
string path,
[MarshalAs(UnmanagedType.LPTStr)]
StringBuilder shortPath,
int shortPathLength);
public static string GetShortPathName(string fileName)
{
if (fileName == null || fileName.Length == 0)
return string.Empty;
if (!Path.IsPathRooted(fileName))
fileName = Path.GetFullPath(fileName);
try
{
int len = GetShortPathName(fileName, null, 0);
if (len > 0)
{
StringBuilder sb = new StringBuilder(len);
GetShortPathName(fileName, sb, len);
return sb.ToString();
}
else
return fileName;
}
catch
{
return fileName;
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
|
|
|
|
|
|
It is a shame that this is not part of the framework and you have to result to using an old API call for it.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
|
|
|
|
|
Ray Cassick wrote:
It is a shame that this is not part of the framework and you have to result to using an old API call for it.
I suppose all we can do is hope for nice updates to the Framework as it ages, I wonder what other functions people are missing from the .NET Framework. I think this might be a survey question in the making.
Nick Parker
You see the Standards change. - Fellow co-worker
|
|
|
|
|
My guess as that once the OS itself becomes more .NET centered this will also change.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
|
|
|
|
|
|
Nick Parker wrote:
I wonder what other functions people are missing from the .NET Framework
The Profile (INI files) functionality from the Win API... how simple and yet annoyingly absent.
Paul
Pleasently caving in, I come undone - Queens of the Stone Age, No One Knows
|
|
|
|
|
Take a look at the System.Configuration namespace. INI file support isn't included because Microsoft is trying to get away from them and into XML. XML is extremely handy for something like this.
I don't know whether it's just the light but I swear the database server gives me dirty looks everytime I wander past.
-Chris Maunder
Microsoft has reinvented the wheel, this time they made it round.
-Peterchen on VS.NET
|
|
|
|
|
David Stone wrote:
XML is extremely handy for something like this
Sure it is, and so is the registry; I'd use both in their place.
But sometimes (usually for legacy reasons or maybe because a user who might want to hand-configure their software is [rightly] scared of the registry and sees XML as too complicated) an INI file is a nice simple answer.
MS have been saying in MSDN for years that Profile API functions are included for compatibility with Win 3.X and yet people still use them. I've seen several questions around the internet (I think mostly here) about reading INI files in C#.
Paul
Pleasently caving in, I come undone - Queens of the Stone Age, No One Knows
|
|
|
|
|
Paul Riley wrote:
MS have been saying in MSDN for years that Profile API functions are included for compatibility with Win 3.X and yet people still use them.
Well there you go. Now, since it's a lot harder, people won't use them . And for those poor fools who really need them, there's always DllImport .
-Domenic Denicola- [CPUA 0x1337]
“I was born human. But this was an accident of fate—a condition merely of time and place. I believe it's something we have the power to change…”
|
|
|
|