|
Use CWnd::SetTimer to start a timer say for per minute and within its handler call CTime::GetCurrentTime and set the returned date onto your static control.
--
======
Arman
|
|
|
|
|
Hi,
i try to help you...
In your view/dialog/frame class you declare a
<br />
UINT_PTR MyTimer
and a Handler to the Event :
afx_msg void OnTimer(UINT_PTR nIDEvent);
in the .cpp
you link the Event with the handler in the MESSAGE_MAP :
ON_WM_TIMER()
your code for the handler :
<br />
void xxx::OnTimer(UINT_PTR nIDEvent)<br />
{<br />
if(nIDEvent == 5)<br />
{<br />
KillTimer(MyTimer);
}<br />
}
and a function which starts/initializes your timer :
void xxx::InitMyTimer(void)<br />
{<br />
MyTimer = SetTimer(5,100,NULL);<br />
}
Good luck
|
|
|
|
|
See here.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
ho i am getting crash often in DoDataExchange(CDataExchange* pDX); i declared as DDX_Control(pDX, IDC_DOWNLOAD_PROGRESS, m_Prog); whats wrong with this code.
Arise Awake Stop Not Till ur Goal is Reached.
|
|
|
|
|
Hi,
the code seems correct.
Check if your control on the Dialog has the ID "IDC_DOWNLOAD_PROGRESS"
And you have a valid CProgress variable m_Prog in your Dialog/View class.
Greetings
|
|
|
|
|
yes i checked both are correct. i am getting crash in release mode.
Arise Awake Stop Not Till ur Goal is Reached.
|
|
|
|
|
and in Debug-Mode all is okay?
is your CProgress a member or a pointer to CProgress?
|
|
|
|
|
its pointer to CProgress
Arise Awake Stop Not Till ur Goal is Reached.
|
|
|
|
|
I suppose that the pointer is allocated before the OnInitialUpdate(before the DDX_Control is executed)
I think you need to debug and step into the functions and look where the error occurs.
you have already a long code? If not so, you can post some pieces
|
|
|
|
|
Dear All
I am in the process of writing one real time program which reads and writes data to and from Parallel port of computer.
Some times I see that CPU usage on my computer goes high and My program cannot read data from port and loss of data occures.
I set my process and thread priority of program as high as possible.
but it is apparant that some times windows OS does not priority of program and give CPU to other processes.
I dont know what is the reason of this High CPU usage on computer.
But if you know What is the source of that and how we can make our computer protected against this problem please let me know.
Regards
Monhi
|
|
|
|
|
Use Real Time OS (RTOS).
Regards,
Paresh.
|
|
|
|
|
how can I download or access this operating system.
Regards
|
|
|
|
|
m_monhi wrote: how can...
By searching for one. For example, VenturCom produces a RTOS. Mentor also produces one. Others.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I'm sceptical about you needing a RTOS. Modern PCs running standard Windows should be capable of
handling parallel port transfer rates using very little CPU, even with standard priority threads.
I'd look into your design a bit. Are you sitting in a loop on a thread somewhere?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I agree Mark.
He's probably using non-overlapped I/O burning a considerable amount of MIPS waiting on a read operation to timeout blocking write operations, or the other way around, with loss of data as consequence.
Manipulating the thread priorities will usually make the problem worse.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: He's probably using non-overlapped I/O burning a considerable amount of MIPS waiting
on a read operation to timeout blocking write operations, or the other way around, with
loss of data as consequence.
Manipulating the thread priorities will usually make the problem worse.
Yeah that's what I meant Well stated!!
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
How to load bitmap and also given text format display on left or right in bitmap in VC++?
Vijayan
|
|
|
|
|
Do you have a bitmap as a resource or a .bmp file ? Could you please be specific ?
Regards,
Paresh.
|
|
|
|
|
If you have a bitmap on resource use of CBitmap but if its a file use of LoadImage and for show it you can use of WM_ERASEBKGND
|
|
|
|
|
Hi, I'm developing an MFC SDI application. I use ActiveX and I wish to show a progressBar during the elaboration time of the AX ( for ex. while loading a report o populing a grid).
I can manage the ProgressBar from all my app but not during the AX's aleborations.
I try to use the timer on a thread, but I'm not able on it and I don't know if it's the better way for do what I need.
Can somebody help me and preferibly post some sample code???
-- modified at 6:24 Wednesday 18th April, 2007
|
|
|
|
|
Not much info to go on here, but let me guess about what I think is going on...
I'll just have a look inside my crystal orb...
In your application you have set up a Single Threaded Apartment (STA) and you're using an ActiveX control from that thread.
At some point you're calling one of the interface methods of the ActiveX control commencing an operation that will take some time to complete. The function call will not return until the operation has completed. During this time you want to display a progress indicator and update it periodically.
If the above is correctly guessed about your situation, then your main problem probably is that your application doesn't process messages while it's executing inside the ActiveX control. The call to the ActiveX is blocking and won't return until finished. This also prevents your user interface from being responsive as well.
There's no sustainable way to fix this. Your main thread has got to process messages if you want to do GUI stuff in that thread.
How it should be done:
The ActiveX control should be implemented to be asyncronous. If an operation is started that will take a relatively long time to complete, the call should return immediately with information whether the operation could be started or not. When the operation completes, the ActiveX should fire an event through a connection point interface. It means that the ActiveX calls an interface implemented by the client. Progress information should be given to the client the same way, but through another method of course.
What could be done:
If the ActiveX control is not your own and you don't have access to the source code for it, there are some workarounds that may do the trick. The preferred solution at the top.
1. If the ActiveX does not have a GUI, you could spawn a UI-thread, initialize another STA and create the ActiveX in that thread. Marshal the interface for the ActiveX back to the main thread to be able to call other functions easily, but when starting lengthy operations you should post messages to the UI-thread so that thread becomes blocked instead.
In your main thread you can update the progress indicator with a timer, typically with CWnd::SetTimer(...) . Post a message back to the main thread when the operation has finished.
2. Spawn a UI-thread from which you display a dialog box with a progress indicator while the main thread is blocked. Update the progress indicator with a timer in the dialog box.
N.B. None of the suggested solutions above is easy and if you don't know how to do it, you will have to ask a lot of questions in the VC++/MFC and COM forums.
Read this article[^] regarding how to create UI-threads if you need to.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for the answer, you check perfectelly my problem.
I have read the article you link and I try to implement the first solutiona you've suggested.
I made my CMyThread class derived from CWinThread class and create the thread in my app when I need to call the ActiveX functions.
I have some problem:
1. In code when I need to create the Thread attach this code:
CMyThread * thread = AfxBeginThread(RUNTIME_CLASS(C4Thread));
but at compile-time it said "It's impossible to convert from 'CWinThread *' to 'CMyThread *'.
WHY this?
2. In which method of my CMyThread class I must put the code to peform (the call to the ActiveX functions) or I need to implement a new function? In thi case how?
Thanks a lot.
|
|
|
|
|
CDRAIN wrote: I try to implement the first solutiona you've suggested
Well, my first suggested solution wasn't not about UI-threads. It was about modifying the ActiveX control since it would be the best designed and easiest solution.
Your problem is due to the ActiveX control being poorly designed, or you're using it in a way it wasn't intended.
Do you have access to the source code for the ActiveX and can you make modifications to it?
I don't want to encourage you to take the path to a less suitable solution (the UI-thread alternative) unless forced to. :->
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Sorry, I want to say that I try your second solution...
I don't have access to the source code for the ActiveX, so I try the UI-Thread.
I try to explain my problem: on my thread I must fill a grid control (the ActiveX) and while this i need to refresh a progress bar.
This is the code I use:
Create the thread in which I'll fill the grid
C4ThrGrid * thread = (C4ThrGrid *)AfxBeginThread(RUNTIME_CLASS(C4ThrGrid));
Call the thread's function that fill the grid
thread->openGrid(&m_wndGrid,str,m_inUseSource);
Close the thread is it right
thread->PostThreadMessage(WM_QUIT, 0, 0);
Is it the right way to obtain what I need?
Why at runtime when I create the thread appear a message box that said "Insufficent Memory"
Help!!!!
|
|
|
|
|
CDRAIN wrote: Sorry, I want to say that I try your second solution...
Quite allright, I was only making sure that what I wrote made sense.
CDRAIN wrote: I don't have access to the source code for the ActiveX, so I try the UI-Thread.
Ok. Too bad, though.
This is, like I wrote earlier, not easily circumvented.
CDRAIN wrote: Can you helo whit my problem?
Yes, I can, but I have a limited amount of time so you shouldn't rely on me solely.
If you're not familiar with the things I mentioned in my earlier post, like UI-threads, STA, marshalling and so on; you should expect quite a learning curve before you're done with this.
But consider that a great opportunity to learn!
Regarding your previous post:
You don't need a CMyThread* member variable. You will only need a CWinThread* variable. The CMyThread class is only needed for the implementation of what the thread should do, respond to messages and what messages to react upon.
Changing the type to CWinThread* will remove your compiler error.
You don't "call" functions in a thread. You comunicate with a UI-thread by posting messages to and from the thread.
Read the article I referred to again, carefully.
The article describes what you have to do, including where to call ::CoInitialize() and ::CoUninitialize() in order to create and tear down the STA.
The first step is to successfully spawn the UI-thread and be able to stop it later.
Before you're finished you also have to:
- Marshal the ActiveX interface back to the main thread with calls to
::CoMarshalInterThreadInterfaceInStream(...) and ::CoGetInterfaceAndReleaseStream(...) - Post a message to the UI-thread when the lengthy operation should be performed with <ode>PostThreadMessage(...)
- Set a timer to update your progress bar and implement the timer message handler with
CWnd::SetTimer(...) and override CWnd::OnTimer(...) - Post a message from the UI-thread when the lengthy operation has completed with
PostMessage(...) - Release the interfaces when you're done in both the main thread and the UI-thread
- Terminate the UI-thread by posting a WM_QUIT message and wait for it to die with a call to
::WaitForSingleObject(...) waiting on the thread handle
I suggest you start a new thread for each question you have and you should probably link to this forum thread to explain the background.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|