|
Have you checked the integer value of the keycode? My guess is that value will be unique to the @ symbol.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Cops & Robbers
Judah Himango
|
|
|
|
|
The value is 50, which is the ASCII value of 2. The KeyData is Keys.D2 | Keys.Shift. Actually, the ASCII value of @ is 64. Any idea? TIA.
|
|
|
|
|
Here is a quote from one of Nish's articles using MFC
Using PreTranslateMessage to handle dialog keystrokes
Very often you hear questions from novice programmers asking
how they can trap keystrokes in a dialog based application.
Presumably they tried to handle WM_KEYDOWN/WM_KEYUP unsuccessfully.
The whole problem is that in a dialog based application the focus
is always on one of the child controls and not on the main dialog
window. So what do you need to do? You need to override
PreTranslateMessage.
How do you accomplish this using C#?
|
|
|
|
|
There is a SystemKey event. Also, a dialog in C# has a property called 'key preview', which I believe means the dialog gets the keyboard message before the control does.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
In your form code, override ProcessCmdKey method.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Cops & Robbers
Judah Himango
|
|
|
|
|
follow this article through should answer your question.
http://www.codeproject.com/csharp/globalhook.asp
|
|
|
|
|
I don't know if anyone else has had this problem with the AxWebBrowser. I have a AxWebBrowser on a form and it works great when I bring up the form for the first time. When I open the form for the second time however the AxWebBrowser control seems to become unattached from the form. It still shows up but it is just floating by itself.
Do I need to use the dispose method for the AxWebBrowser when I close the form? If so how do I create the AxWebBrowser during runtime? I tried to do this but I'm doing something wrong because the Browser doesn't show up. I tried this code in the form's load event.
AxSHDocVw.AxWebBrowser WebBrowser = new AxSHDocVw.AxWebBrowser();<br />
WebBrowser.Location = new System.Drawing.Point(8, 8);<br />
WebBrowser.Size = new System.Drawing.Size(100,100);
|
|
|
|
|
I need to know which could be the best way to communicate two or more applications that could be in oneself PC or in different machines. Which is more efficient, the use of threads, services or another thing.
Thank you anyway.
Anglada
|
|
|
|
|
There is no single best way, largely because the definition of "best" changes from one application to another. In order for someone to give you good advice here, you should describe as much as you can about:
- frequency of communication
- approximate size of the data (both directions)
- all different connection options between the computers
- whether other software, such as firewalls, are a consideration
- the way a user will interact with your software
- anything else that may impact the meaning of "best way to communicate" for the software under consideration
John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
|
|
|
|
|
The frequency of the communications will be high. I have four modules, and the communication of a module to the rest (the other ones PCs ) will be unidirectional, but I need that this communication be fast and constantly, the size of the information is small. In some cases the communication will be bidirectional.
Where I can find information related with this topic.
Anglada
|
|
|
|
|
Based on this small bit of information, the closest widely-known model would be that used by MMORPGs (massively multi-player online role-playing games). They commonly use UDP as a primary element of their communications. This might be overkill for you, though. Your definition of "fast and constantly" may be less demanding.
John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
|
|
|
|
|
|
Hi,
I measured the time the following code executes on a 64-bit computer:
for(int x = 0; x < 100000000; x++)
{
double a = 1234.56789 * 1234.56789;
double b = 12345.6789 * 12345.6789;
double c = a / b;
}
Testing cases:
1. code compiled in .NET 2003 (32-bit)
2. code compiled in .NET 2005 (x86; 32-bit)
3. code compiled in .NET 2005 (x64; 64-bit)
Results:
case 1 was the fastest
case 2 was a little bit slower than case 1
case 3 was around 5.5 times slower than case 2
I expected case 3 is the fastest (then case 2 and, finally, case 1).
Does anyone know why that happens?
Thank you,
|
|
|
|
|
Case 3's being so slow is weird, but since all x86 processors do floating point math using an 80bit denormalized value internally there shouldn't be any architectural level difference in the performance. At a guess, 64bit machines are still rare enough to be a relatively low priority for the optimizers.
|
|
|
|
|
gabser wrote:
Does anyone know why that happens?
I'm just guessing, but aren't 32 bit integers slower on 64 bit machines? Did you try using a 'long' on the for loop, instead of an 'int'?
|
|
|
|
|
I changed int with long.
I got the same result.
|
|
|
|
|
Another possibility (that I haven't checked): Does the .NET 2005 version you are using contain debug code, while the .NET 2003 version does not?
John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
|
|
|
|
|
|
You realize that I was referring to the framework itself, and not your code?
John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
|
|
|
|
|
Just to make things a little more confusing. In the Release version or youre code, you're only doing one math problem at runtime. The optimizer will evaluate the math of 2 constant values into a resultant constant and substitute that constant for the code used to get it.
You're actually just mov'ing two float64 constants to the two locations a and b. Then the division takes place and is assigned to c as a float64 result.
You're code is actually this:
for(int x = 0; x < 100000000; x++)
{
double a = 1524157.8750190521
double b = 152415787.50190521
double c = a / b;
}
But, that's not the problem. The problem is that your still running under a 32-bit OS. You can't use any of the 64-bit instruction set, including math instructions, until you replace your OS with Win64 enabled Windows. Until then, your doing 64-bit math using only the 32-bit instruction set, which, oddly enough, is slower on the 64-bit chips.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
OS is Windows Server 2003
Enterprise x64 Edition
Service Pack1
|
|
|
|
|
Then I have no idea what's causing it.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Well, other than the .NET Framework 2.0 is still a beta and not optimised for performance benchmarks yet.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
My best guess is that .NET 2005 is beta still. Try this again in November when it's RTM.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Cops & Robbers
Judah Himango
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
