|
|
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
|
|
|
|
|
I am calling a dll from C#.
The dll is called from a single function call in C# (dllimport ...)
The dll produces data, which I want to access in real-time as and when it is generated in C#. However, the single function call will obviously only return the final answer.
How can I setup either the dll or the C# to give me data as I require? Do I need to make an additional function call in C# that gives me access to the data or will the dll have to setup to send data back periodically? If so, how can I do this?
Your help is appreciated.
-- modified at 12:30 Tuesday 6th September, 2005
|
|
|
|
|
Let me ask if I'm understanding your problem correctly. Your C/C++ dll produces data in real-time, but only gives the final result back, yet you want your C# code to have access to the real-time data? If that's what you want, then you have a few options. One option is to split up the C/C++ function into several functions, each returing parts of the real-time data. Another option is to pass a delegate type to the C/C++ dll which will be called from inside the C/C++ dll as it receives real-time data. I'd recommend the latter option.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Cops & Robbers
Judah Himango
|
|
|
|
|
Hi,
Yes that's what I'm trying to do. The dll is written in Fortran so splitting up the routines is definitely not something I want to do.
I was half-expecting the answer to be on multithreading whereby a call would be made to the main process and periodically a call would be made to the fortran routine that keeps the data with a flag so tell C# that new data has arrived.
Just for interest, would this be a good idea?
However, I will try as you suggest.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
