|
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.
|
|
|
|
|
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…”
|
|
|
|
|
It looks like DirectShow 9 lacks support for managed code. I've seen people talking about creating COM wrappers and interop to support this.
I have glances at the DirectX.NET articles here at CodeProject, but it doesn't cover what I am mainly interested in: DirectShow Editing Services (DES). The Dexter library also lacks this.
I guess some of you have already created this stuff, so my question is: Where can I find this kind of libraries?
-Øyvind
|
|
|
|
|
In the past, I have been working with DirectShow, and from what I know :
- DirectShow Editing services is available since DirectX 8.1. May be release 9 adds a few interfaces, but that's not a requirement.
- DirectX objects are COM objects, and embed a tlb. For instance, DirectShow's type-library is embedded in quartz.dll. Who prevents you from calling this "tlbimp.exe quartz.dll" to get the interop library ? I don't know why you should install DirectX 9 just for that purpose.
Of course, once you have that interop type library, you need to rewrite the samples from C++ to C# or other .NET languages. That's probably what DirectX9 provides you for free (but again, nothing really required).
|
|
|
|
|
.S.Rod. wrote:
DirectX objects are COM objects, and embed a tlb. For instance, DirectShow's type-library is embedded in quartz.dll. Who prevents you from calling this "tlbimp.exe quartz.dll" to get the interop library?
Of course you can. What I meant was that I was hoping that DirectShow 9 would fully be supported with managed code. But it didn't.
I don't think that the DirectShow Editing Services is covered in quartz.dll. Am I right?
I guess someone already has converted the DirectShow Editing Services interfaces from IDL to C#. Where can I find this?
As you may guess I am interested in all information I can get in how to use DirectShow Editing Services from C#.
Thanks for any help.
-Øyvind
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
