|
The Scribble example from MSDN is possibly your best starting point. It already contains all the framework and most of the drawing code you need along with mouse interaction which you won't want at least to start with. It should be straight forwrd to adapt it to read a file of axis and point data and generate a graph. 3 hours tops 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I developped a charting control some time ago. Check my sig for the link. There are some other similar controls in the same category also.
|
|
|
|
|
Hi,
I have VC 6 in my machine. I need to install the VC 2005. I have to use VC 6 for creating the release of projects. So if I install the VC 2005, will it affect the VC 6? Also will it affect the release product?
Thanks in advance.
- NS -
|
|
|
|
|
I have VC6 and VC2005 installed on my machine and I don't have any problems.
|
|
|
|
|
Thank you for the information. Since I have to do it in my office computer, I am a little bit confused about that. Someone told me that it would affect the building of projects and the release will not be reliable. He said that the dlls and/or lib of the VC 6 might be replaced by that of the VC 2005.
- NS -
|
|
|
|
|
NS17 wrote: Someone told me that it would affect the building of projects and the release will not be reliable.
|
|
|
|
|
Not you. I am sure.... 
- NS -
|
|
|
|
|
I have installed VC6, VC 2003 and VC 2005 on one machine. It is working fine since then.
For ease of use you better dont change the default installation settings as directories. 
Greetings from Germany
|
|
|
|
|
I installed vc6 at first, then I installed vs2005, at last, I uninstalled vs2005. But the file associations with vc6 are lost (.dsw/.dsp/.c/.cpp etc.)  . I don't know the principle of file association by now. Who can help me to find them. Thanks very much.
|
|
|
|
|
This happens on my machine, but I can still right click on them, choose "Open With" then choose VC6 or VS2005. I didn't do anything special to make this happen - some guru may be able to explain if it doesn't work for you.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
If you installed VC8 on top of VC6 then the files associations in the registry will go to VC8. In order to get them back just right click and select "open with", though it would be better to just do a clean install of VC6 because you don't know what else has been messed up.
Waldermort
|
|
|
|
|
i want to post message from one dialog to another dialog
|
|
|
|
|
If your dialogs have a parent child relationship where one know about the window handle of the other then the chances are you want to look at WM_NOTIFY. If not or you're doing something way out like multiple UI threads then you'll need to post a lot more details.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Cant you use PostMessage API?
- NS -
|
|
|
|
|
bhogavalli suresh wrote: i want to post message from one dialog to another dialog
Ok, so what's the problem? 
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
ANy can help me for postmessage and send message ,how to prcessed with it
|
|
|
|
|
You can use PreTranslateMessage to process they...
Russell
|
|
|
|
|
bhogavalli suresh wrote: how to prcessed with it
Means!!!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Your message was not posted correctly. Please re-send it.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello !
I would like to access the serial port in a multithreaded application. What I would like to do, is to have one thread which is responsible for reading continuously the port (so, an endless loop). I would like to make a blocking read (so that I don't have a busy loop for reading). So far, so good, I can configure the COMMTIMEOUTS this way:
- ReadIntervalTimeout = MAXDWORD
- ReadTotalTimeoutConstant = 10
- ReadTotalTimeoutMultiplier = MAXDWORD
So, this means that the following happens (from MSDN):
If there are any bytes in the input buffer, ReadFile returns immediately with the bytes in the buffer. <br />
<br />
If there are no bytes in the input buffer, ReadFile waits until a byte arrives and then returns immediately. <br />
<br />
If no bytes arrive within the time specified by ReadTotalTimeoutConstant, ReadFile times out. <br />
I'm doing that only to check if my application terminates or not (otherwise, I could have an infinite timeout).
This part works fine. But the operations on the serial port are serialized meaning that when I want to write something on the port from another thread, it will wait until the read operation finishes (so, in the worst case it can wait 10 msec).
I'm developping an application on Windows Mobile 5 and it should be real-time (particularly for that part of the application).
I could use overlapped operations but it seems that it is not supported on windows mobile 5
I could also make the read operation returns immediately but then I will need to put a little sleep (1 msec) between each read operation and I do not want to do this.
So, if anybody knows a way to read and write simeltaneously on the serial port, it will be really appreciated.
|
|
|
|
|
Hmm, a tricky one. I would consider having the same thread doing the reading and writing, taking it's orders from a queue and prioritising writing over reading. In other words do the very short timeout read 1 or 2 msecs then if there is anything to write, write it otherwise go around again and do another read or sleep if no read is required.
Remember on Windows Mobile your reader/writer thread should not have a raised priority if you do this sort of thing or no other thread will ever get a look in as the threading is purely priority based rather than preemptively time sliced.
Remember also that COM ports are relatively slow even in comparison to bandwidths on a mobile device so don't burn processor cycles blocking on a slow port just to make sure it runs flat out. You should easily be able to flood the port or read at full speed with a fraction of the available runtime.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: Hmm, a tricky one. I would consider having the same thread doing the reading and writing, taking it's orders from a queue and prioritising writing over reading.
We considered that but that wouldn't solve the problem: if there is nothing to write, we will read the serial port (even if there is nothing coming in) and the read will return immediately. If there is still nothing to write, we'll read directly again. Thus, we'll have a busy loop that consumes CPU cycles (and which is an above average priority thread, so it will screw everything).
Matthew Faithfull wrote: In other words do the very short timeout read 1 or 2 msecs then if there is anything to write, write it otherwise go around again and do another read or sleep if no read is required.
Well, that's the problem: we don't want to wait for 1 or 2 msec (waiting for the read operation to complete) or to sleep some msec in between.
Matthew Faithfull wrote: Remember on Windows Mobile your reader/writer thread should not have a raised priority if you do this sort of thing or no other thread will ever get a look in as the threading is purely priority based rather than preemptively time sliced.
If the read and write threads are just waiting (like a blocking read), then this problem is automatically solved. And that's exactly what we want to do: give the read and write thread high priority but they just wait until something happen (data has been received or data need to be transmitted).
But I think we found another way to deal with the problem: bu using WaitCommEvent[^]. In the loop that read the port, we simply call this function before the read. Once the function returns, we check if the event was because of data coming in. If that's the case, then we read the data. So, this loop simply waits until data comes in.
|
|
|
|
|
That sounds good and probably simpler than by next suggestion which would have been to check if IOCompletion Ports work on Mobile 5.0. They would allow you to do the same thing.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Cedric Moonen wrote: if anybody knows a way to read and write simeltaneously on the serial port, it will be really appreciated.
To my knowledge this is not possible on Windows Mobile, since you cannot use overlapped I/O.
By not using overlapped I/O the driver has to complete each IRP before it begins executing the next one.
This enforces a synchronous behavior towards the driver and the point of using different threads for reading and writing is lost.
I see two scenarios with two different questions of importance:
1. You're using handshaking so you won't lose any data that is supposed to be received. Writing has priority over reading and your concern would probably be how long you can delay a write request.
2. You're not using handshaking so you may lose data that is supposed to be received unless you read frequently enough. Reading has priority over writing and your concern would probably be how fast you need to read to avoid loss of data.
Suggestion:
I would try having a queue with messages to be sent that is synchronized with a semaphore which the thread that does the reading and writing waits for. When the semaphore is signaled you write the next message and then issue a read request. If the semaphore is not signaled the wait function will timeout.
I would tweak the COMMTIMEOUTS::ReadTotalTimeoutConstant and the timeout value for the wait function to find a suitable balance between reading and writing depending on whether you're using handshaking or not.
I would avoid ::WaitCommEvent() since it requires something to happen on the UART for it to return. If nothing happens your call may result in a deadlock. If your calling thread is preempted after the write request yet before the request issued by ::WaitCommEvent(), all data may have been transmitted and the call may never return.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hello
Is it possible to know the last date/time when a hard drive / USB flash drive was formatted? Please let me know if there is any tool which can help me do this.
Thanx
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
