|
You may use CreateProcess to start TestProg and then WaitForSingleObject on TestProg handle.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Sir,
Return value of WaitForSingleObject can be one of the following-
WAIT_ABANDONED, WAIT_OBJECT_0, WAIT_TIMEOUT, or WAIT_FAILED. How to get application returned value ?
|
|
|
|
|
You may call GetExitCodeProcess whenever WaitForSingleObject returns WAIT_OBJECT_0.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
|
I am using following code to send message to remote machine through sockets, I am calling mentioned code when a button of MFC dialog based app is clicked and it is working fine. But I don't know how to receive messages from remote machine through sockets.
Can anyone please guide me how to receive messages in dialog based application through socket?
WSADATA w;
SOCKADDR_IN target;
<br />
int error = WSAStartup (0x0202, &w);
<br />
if (error)<br />
return 0;<br />
<br />
m_sckt = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (m_sckt == INVALID_SOCKET)<br />
{<br />
return 0;<br />
}<br />
<br />
target.sin_family = AF_INET;
target.sin_port = htons (PortNo);
target.sin_addr.s_addr = hostname;
if (connect(m_sckt, (SOCKADDR *)&target, sizeof(target)) == SOCKET_ERROR)
{
return 0;<br />
}<br />
send(m_sckt, "Test", 5, 0);
Thanks,
Mushq
|
|
|
|
|
Hi all.
I am Comparing two strings.....when both are in English...Its Comparing Fine..
But if One string is in Japenese...Its giving runtime error..
Ex..
I am Comparing ("INBOX",bstrFolder)......
when bstrFolder is in English Letter i.e INBOX....It Compares Fine..
But when it is in Japenese Letter its not Comparing..
I hope you got me...
Thank you
manju
Hi..
I am Mnaju.I have Completed my B.E Computers Science.Lokking for a job.I am interested in VC++
manju
|
|
|
|
|
Please post the code.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
bstrSourceQuery = _T("select "
" \"DAV:href\""
" from scope ('shallow traversal of \""
+ bstrSourceFolderUrl+_T("inbox")+ "\"') "
" WHERE \"DAV:isfolder\" = false AND \"DAV:ishidden\" = false"
" ORDER BY \"urn:schemas:httpmail:datereceived\" DESC");
AfxMessageBox(bstrSourceQuery);
m_pUserConnection->Provider = _T("msdaipp.dso");
m_pUserConnection->Open((_bstr_t)strFolderURL, bs_UserName,bs_UserPwd, 0);
bstrSourceFolderUrl += _T("inbox");
m_pUserRecord->Open((_variant_t)bstrSourceFolderUrl, m_pUserConnection->ConnectionString,
adModeRead, adFailIfNotExists, adOpenSource, bs_UserName,bs_UserPwd );
Hi..
I am Mnaju.I have Completed my B.E Computers Science.Lokking for a job.I am interested in VC++
manju
|
|
|
|
|
I see no string comparison in your code.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
See Actually I am Reading the mails from Inbox.....If the mailbox is in Japenese its not reading ...I am not Comaparing it...If it is Inbox it opens
Hi..
I am Mnaju.I have Completed my B.E Computers Science.Lokking for a job.I am interested in VC++
manju
|
|
|
|
|
|
Hi,
I am having an application where we mainly do analysis on images being grabbed in real-time. The current version basically works in the following way- Loop[^]
the critical section code within writing into shared buffer looks as follows
CCriticalSection CritSect;<br />
CritSect.Lock();<br />
memcpy(SharedBuffer, cap_buffer, FrameSize);<br />
Timestamp_FrameWrite = LoopStart->GetTimeDiff();
CritSect.Unlock();
and the code within reading frame is as follows
CCriticalSection CritSect;<br />
CritSect.Lock();<br />
memcpy(proc_buffer, SharedBuffer, FrameSize);<br />
Timestamp_FrameRead = LoopStart->GetTimeDiff();
CritSect.Unlock();
From the block diagram you will notice that camera thread will call the function to write the newly captured frame into shared buffer for every 20ms (since the exposure time is 20ms) and this is also verified by finding the difference between two successive "frame write" timestamps (~18ms to ~22ms). This is all fine.
Now when I find the difference between two successive "frame read" timestamps, it always gives me either ~15ms or ~31ms as shown below
15.8758<br />
15.6622<br />
31.008<br />
15.845<br />
15.605<br />
31.062<br />
15.819<br />
15.663<br />
15.748
but when you average these over total number of frames read, it give ~20ms which shows that it is not dropping frames while reading (in other words its analyzing all frames being captured). So, the question is why is the "frame read" timestamp doesnt correspond to frame rate (i.e ~20ms or ~49Hz), this is the same case even when I am not doing any analysis (which hardly takes more than 10msec)?? I have to say that the loop function runs on a TIMER which has 5msec timeout value.
-thanks
PKNT
|
|
|
|
|
Can you share more about how do you measure time difference two frames?
-Saurabh
|
|
|
|
|
the time between two successive frames is just a simple subtraction between two successive TimeStamp_FrameWrites. Same applies with TimeStamp_FrameReads. For example, lets say the LoopStart when we start the loop is 0ms then the TimeStamp_FrameWrite is always ~20ms, ~40ms,~60ms etc, which is same as camera exposure time. The TimeStamp_FrameRead should also be multiples of ~20ms , but its always either ~15ms or ~30ms as I mentioned earlier. Hope I am clear now.
PKNT
|
|
|
|
|
What is the source of these timestamps?
Aside from the high-resolution performance counter, there's no timers available on
Windows with a resolution better than ~15ms.
Also, your critical sections are useless as shown. A critical section will only
work if threads lock on the SAME critical section object. If your frame read and write
code shown is executed on separate threads, you effectively have NO syncronization.
Mark
|
|
|
|
|
The source of timestamps is a small custom defined class with calls to QueryPerformanceCounter/frequency. Yes, those critical sections have no real use as far as I tested and we dont use in our application. Actually another lab took our code and modified it for their application and their programmer left without actually resolving these issues and they want me to check it. The timing is pretty much accurate for 'frame write' around ~20ms, its the 'frame read' that are not what we expect.
PKNT
|
|
|
|
|
Interesting.
The timestamps look like something somewhere is relying on a low-res timer...
suspiciously with an accuracy very close to the tickcount in Windows
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
But its not either ~15ms or ~31ms all the time, when he displays some real-time graph from analysis of each frame, the time diff between two successive frame reads is all over the place from ~2ms to ~42ms. Maybe I have to provide with more clear code to understand. But anyways the basic idea of their application is, camera frame grabbing is always ~20ms so, as soon as a frame is grabbed and while we are doing analysis of the current frame, we have the camera to capture the next frame which will take another 20ms and since we know analysis doesnt take more than 10ms, theoretically the loop has to wait for the camera to get the next frame for the rest of 10ms while the camera is capturing next frame. What would be the best way to accomplish this, I have some ideas that I would like to try on Monday, but meanwhile if you come up with something, please lemme know.
PKNT
|
|
|
|
|
Kiran Satish wrote: I have to say that the loop function runs on a TIMER which has 5msec timeout value
What kind of timer?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Its the default MFC Timer that we initialize using CWnd::SetTimer function, but the camera grabbing runs in a different thread.
PKNT
|
|
|
|
|
Kiran Satish wrote: ts the default MFC Timer that we initialize using CWnd::SetTimer function
Not good. I recommend multimedia timers (after all, this is what they're for!).
IME, on XP+ they are pretty precise to 1ms
Kiran Satish wrote: but the camera grabbing runs in a different thread
Are you responsible for grabbing frames at the interval you want or does the
hardware/driver signal you somehow when a frame is available?
IME, the ideal situation is when the driver can signal an event that wakes a thread for each frame.
If that's not possible and you have to grab frames at a given interval, the next best performance is
with multimedia timers.
I personally wouldn't use Windows timers except for situations where timer resolution doesn't matter at all.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I never used those multimedia timers, maybe its time for me to use them . Coming to camera grabbing, we use a command from the frame grabber's library and whenever you call that command, it grabs a frame with a set predefined exposure time which, in our case is 20ms. So unless you call that command it wont capture a frame.
PKNT
|
|
|
|
|
In that case, it seems like you don't need a timer.
The grabber thread can loop grabbing frames - the exposure time will
throttle the loop to 50 fps.
After each frame is grabbed, set an event that wakes the processing thread.
The processing thread can loop waiting on the grabber event. When the event
is signaled, it can process the frame and wait again.
If your processing time is ~10ms your frame-data critical section should never
have to wait/block.
Ideally, you'd want to eliminate the need for the critical section altogether
if possible, even if you have to copy the frame data to another buffer on the
processing thread.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Here's what I meant in the last post:
While capturing
{
Capture frame (20ms exposure)
Add frame data to shared buffer
Set frame-grabbed event
}
While processing
{
Wait on frame-grabbed event
Copy data from shared buffer
Process the data
}
You still need to synchronize access to the shared buffer. Only lock
long enough to copy data to and from the buffer, then release the lock
immediately.
That's all based on ideal situation where processing time is always
~10ms.
In reality, your threads can (and will be) interrupted by other threads
in the system. If it's critical to process every frame, then change the shared
buffer to a FIFO queue of some kind. The grabber thread can queue each frame
and the processing thread can dequeue frames. If the queue holds pointers to
frame buffers, then accessing the queue is fast, which makes lock time shorter.
That's pretty much how I handle audio capture, where I want every sample regardless
of thread timing fluctuations.
Does that make sense?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yeh, it makes sense, thanks a lot. Actually thats what I like to implement , but I am not thinking of implementing locking of shared buffer earlier. But before implementing this, I would like to time exactly how much time each function in the processing thread is taking in worst case. Based on those timings, I would implement queuing on the captured frames. I have to change a lot of code thats currently been implemented. Since, this is not our lab's work, I might be working on and off on this. So, will keep here posted on how it goes  .
PKNT
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
