|
In executes debug as well as in release mode.
Even if write some statements in Display() function it will execute.Its not because of empty function.
|
|
|
|
|
CAdd *pObj = NULL;
pObj->Display();
Call will be succeeded as long as none of the member variables of CAdd is referred in Display(). When pgm loads, a class will be having only one copy of all its member functions for all class variables we create, but will be having its own copy of member variables for each class variables. So members variables will be allocated only when an instance of class is created but there will be already a copy of all member functions even if no instance of class is created. Hope you understood how the calls to Display is succeeded above.
|
|
|
|
|
Yes I understood your explanation.
But still i am not clear with Display() function call with NULL object.
|
|
|
|
|
compiler just examines the type of pointer and so redirect the function call to the location where Display() is loaded. You just write some statements in Display(), put a brake point there and examine 'this' pointer. You can see it as NULL. Whenever you access any of the member variables, then 'this' pointer will be used, and as it is NULL an access violation will be occurred.
|
|
|
|
|
Making Display virtual would make a much more interesting problem.  The pointer to the object is NULL so the v-table pointer would be invalid and should crash and certainly would if the nonexistent class instance was being called through a base class pointer somewhere. However, in this case the compiler could verify the actual type of the object and go directly to the v-table and make the call in the name of efficiency.You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
CAdd* pObj = NULL;
pObj->Display();
Compiler actuall transforms the call to some thing as follows:
void Display(CAdd * const this)
{
...
}
so, I think as long as Display() is not accessing any of the members of the class CAdd, it is safe to call Display() with a NULL ptr.
|
|
|
|
|
Because even if you are a death man, you can still breath, because your're still a member of the species.
Well, you know, the OOP mapping to the real world should break at some point...
 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]
|
|
|
|
|
hello, my application reads data from LPT port , by data register (wich is the data for my app) and by status register( wich decribes the origin of data).I am using intruccions Inp32(Register), this is a piece of code in wich i do the adquisition:
<pre>
aux2=Inp32(Status);
aux=Inp32(Data);
</pre>
It's working but , this is performed between 30useconds intervals , and in some cases it seems that the O.S. (embeded Win98SE) is doing another thing between this two instructions, and when the O.S. come back to execute the second instruction , the data don't belong anymore to the origin indicated by the first instruction, so , is there any way to deny to the O.S. do another thing between this two instructions??
|
|
|
|
|
Hi,
AFAIK you can make a piece of code almost atomic by temporarily raising the thread priority to REALTIME, then restore it (don't run REALTIME for more than a few dozen microseconds!). That would be fine most of the time, however a high-priority interrupt, a DMA operation, or another REALTIME operation, may steal the CPU from you for a short period.
Warning: I doubt changing the priority twice will reliably be handled in 30 microseconds, so it may not be good enough.
If that is insufficient, the official approach is to write a driver.
Is your PC generating the 30 usec tacting, or is your peripheral? how do you that?
If it isn't a potential data overrun problem you are facing, the system-level approach would be to use two-way handshake, i.e. the PC reporting back it has read the data, so the peripheral is allowed to present the next data. Doing so, the communication could slow down temporarily while maintaining good overall bandwidth.
|
|
|
|
|
Thnaks for your reply, answering to your question , is the periferal who generates the 30usec clock.
Handshake, good idea, but that decrease speed data adquisition, and i need to perform a "real time" adquisition lets say.
So it's interesant the idea that you refer in the first paragraph, increase the priority , how can i do that?
|
|
|
|
|
|
Thanks LUC , i will work on that , but tomorrow , here in Argentina is 0:55 AM , so im going to bed now.
|
|
|
|
|
timbk wrote: s the periferal who generates the 30usec clock
and is your code getting a signal (interrupt, event) every 30 usec, or are you just sitting in a polling loop?
if so, you would need to turn the entire piece of code into a REALTIME section, not a good idea. How long does your acquisition take? milliseconds? longer?
|
|
|
|
|
there is a thread running in at the same time the main thread, this new thread created for the acquisition is always checking the state of a bit in status register to know when there is a valid data present in data register, so do you think that is not a good idea to set a realtime priority to whole thread?
I'm not using interuptions, i dont know how to do this in Win98 , it's possible handling interuptions in Win98??
|
|
|
|
|
When I was using Win98 (that is 10 years ago), PC hardware wasn't powerful enough to make floppy drives work reliably with interrupts, so each floppy access caused the entire system to temporarily freeze.
The realtime thread performing its polling loop will monopolize a CPU core.
If your system has a single-core CPU and you will set realtime priorities, the same will happen as on old systems with floppy activity; if you are running on dual-core or better, you might be all right with one thread at realtime, so other threads can still be swapped in and out to serve the user.
|
|
|
|
|
if you can't live with the consequences, the one good way out is to add a sufficiently large memory to your peripheral, so the communication no longer poses a real-time requirement. That is what I did consistently when interfacing with image capture devices and feeding the images (up to 100MB) to a Windows PC, even when using modern PCs, operating systems, and buses.
|
|
|
|
|
| Use a proper real-time operating system if you want that sort of access to the hardware - Windows really doesn't cut it for real-timer operations... Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
Looking at all methods for richedit
there doesn't seem one to get the number of lines whitin the Client area
was wondering if the following code makes sense
TEXTMETRIC tm;
CDC* pDC = myrichedit->GetDC();
pDC->GetTextMetrics(&tm);
myrichedit->ReleaseDC(pDC);
CRect r;
myrichedit->GetRect(&r);
long numlines = (r.bottom - r.top) * tm.tmHeight;
|
|
|
|
|
you would need a division, not a multiplication.
and then there are some extra factors: rounding to an integer, and when applicable the height of a horizontal scrollbar.
|
|
|
|
|
Just had an idea setting the width and height in EN_REQUESTRESZIE notification handler
void CprogDebug::OnRequestResize( NMHDR* pNMHDR, LRESULT* pResult )
{
if(pNMHDR->code == EN_REQUESTRESIZ)
{
REQRESIZE* prr = (REQRESIZE*)pNMHDR;
TEXTMETRIC tm;
CDC* pDC = myedit->GetDC();
pDC->GetTextMetrics(&tm);
myedit->ReleaseDC(pDC);
myedit->numlines = ((prr->rc.bottom - prr->rc.top) / tm.tmHeight);
myedit->linewidth = ((prr->rc.left - prr->rc.right) / tm.tmAveCharWidth);
}
*pResult = NULL;
}
|
|
|
|
|
Greetings,
My problem is that I am spawning multiple modeless CPropertySheet dialogs from my application but the closure of the CPropertySheet dialog does not destroy the pages that have been added.
I can see from the trace statements that the destructors for the individual pages are called but if I try to re-spawn the CPropertySheet I find it already has pages added????
I have tried creating my own class and using the following code in the destructor
while (this->GetPageCount())
{
this->RemovePage(this->GetPageCount());
}
This compiles ok but fails on execution.
Where am I going wrong?
Many thanksAlan
|
|
|
|
|
Try this as the WM_DESTROY handler for the property sheet -
BOOL CPropsSheet::DestroyWindow()
{
for (int p = GetPageCount () - 1;p > -1;p--)
RemovePage (p);
return CPropertySheet::DestroyWindow();
}
I suspect the problem lies in your RemovePage call. The page count page indices are 0-based; RemovePage(GetPageCount()) is trying to remove a non-existent page.
[edit]
edit for clarity
[/edit]L u n a t i c F r i n g e
modified on Tuesday, March 9, 2010 7:19 PM
|
|
|
|
|
Hi,
1.
aren't the tab pages numbered from 0 to count-1, which would mean you are (not) removing a non-existing page forever?
2.
you could remove the first tab page in a loop, until none remain. simpler code, the drawback is tab pages now could move on the screen while your loop executes.
|
|
|
|
|
Using the DestroyWindow seems to work fine and taking into accout the base for the count makes all the difference  ( Doh!)
Thank you both.Alan
|
|
|
|
|
I've spent a lot of time trying to figure this out. I've never seen anything like this.
My main program uses a static library. Both the main program and static library are compiled with VC++ 2008. The static library contains a global variable which is accessed by the main program (I know it's generally considered bad practice, but I'm ok with the undefined initialization order). The global variable is of course defined only once (without the 'extern' keyword), and the 'extern' definition of it is in the relevant header file.
That global variable is a pointer to an object that is dynamically allocated.
The problem is this: While the control flow is in the main program, the global variable is accessible and valid, put the variables of the object it points to (which was dynamically allocated) are empty (set to 0)! This is so weird. Immediately when the control flow is back in the static library, the variables of the object that the global variables point to are ok again.
The global variable (which is a pointer) points to exactly the same memory address both when control flow is in the main program and in the static library.
As if that's not weird enough, during runtime, the debugging "Watch" feature of VC++ 2008 shows that the variables of the object pointed to by the global variable are ok! Only by assigning those problematic variables to other variables I can see that their value is messed up.
Anybody ever experienced anything like this?
Thanks!!!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
