|
PS_DOT would come pretty damn close no...?
If you need it exact you'll probably have to write your own.
You might wanna check out
Line Drawing explained
"An expert is someone who has made all the mistakes in thier field" - Niels Bohr
|
|
|
|
|
Yuck, I hate using them. But what is a fellow to do? The CWinApp theApp object is a global. And so I have this static data member in one of my classes, and I want it to be destroyed last (or at least after the CWinApp object is destroyed). Is there is any way I can do this? Or any alternative to using that static data member, yuck...?
Thanks!
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
Create it with new in the CWinApp constructor and destroy it with delete in the CWinApp destructor.
"An expert is someone who has made all the mistakes in thier field" - Niels Bohr
|
|
|
|
|
Nope that won't do. It's a multithreaded app, and I don't want to be accessing the CWinApp through another thread. But I've figured it out now, as someone mentioned on another thread that you can use #pragma init_seg(lib). Kind of a hack, but it'll do for now, until a better solution comes up.
Thanks though,
Swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
I have external device. The device is connected with the computer through the serial-port. I send on the device number (signal), if it answers, the necessary procedure is started. I can use WaitCommEvent() for event (signal, EV_DSR), but if devise doesn't answer, WaitCommEvent will wait indefinitely, but i need to wait about 5 sec. I used WaitForSingleObject, but it doesn't work!
I don't know why. In what my error?
HANDLE port;
DWORD bc;
DCB dcb;
char buffer[100];
DWORD dwBlockSize=512;
void *szBuffer;
int numb=255;
BOOL fSuccess;
OVERLAPPED event;
DWORD dwEvtMask;
ZeroMemory(&dcb,sizeof(DCB));
strcpy(buffer,"baud=1200 parity=N data=8 stop=1");
BuildCommDCB((char*)&buffer,&dcb);
dcb.fRtsControl = RTS_CONTROL_ENABLE;
port=CreateFile("COM1",
GENERIC_READ|GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
GetCommState(port,&dcb);
if(port==INVALID_HANDLE_VALUE)
{
CloseHandle(port);
}
SetCommState(port,&dcb);
HeapFree(GetProcessHeap(),0,&dcb);
szBuffer = malloc(dwBlockSize);
memset(szBuffer, numb, dwBlockSize);
WriteFile(port,szBuffer,sizeof(szBuffer),&bc,NULL);
free(szBuffer);
fSuccess = SetCommMask(port, EV_DSR);
event.hEvent = CreateEvent(NULL,FALSE,FALSE,NULL);
//Wait for signal
if (WaitForSingleObject(event.hEvent, 5000) == WAIT_OBJECT_0)
{
//procedure
}
else AfxMessageBox("There is no signal from the device");
CloseHandle(port);
|
|
|
|
|
Two questions: Where is the event.hEvent signaled? Are you waiting for the event to become signaled or waiting for it to time out?
If I understand your question you need to test for WAIT_TIMEOUT not WAIT_OBJECT_0
|
|
|
|
|
i'm using mfc, with cview as the base class. i can't find any books that shows how to add grid lines. i was wondering if you guys knew how?
|
|
|
|
|
I don't think there is a DrawGrid member function in the default CView class.
You'll have to write your own.
BOOL CTestView::DrawGrid(CDC* pDC, UINT nWidth, UINT nHeight, COLORREF clrGrid)
{
CRect rcArea;
GetClientRect(&rcArea);
HPEN hPen = CreatePen(PS_SOLID, 1, clrGrid);
SelectObject(pDC->m_hDC, hPen);
int x, y = 0;
for(y=0; y<=rcArea.bottom; y+=nHeight)
{
pDC->MoveTo(x, y);
pDC->LineTo(0, y);
for(x=0; x<=rcArea.right; x+=nWidth)
{
pDC->MoveTo(x, y);
pDC->LineTo(x, 0);
}
}
return TRUE;
}
Your gonna probably wanna tweak this. For example
becuz i don't use the CPen class(I dunno why, i just never do) I'm pretty sure your going to want to restore the original object in your selectObject, cuz it leaks and each time you call DrawGrid which is lots cuz it's called in OnDraw you'll leak and your GDI will go for sh*ts eventually.
Anyways hope this helps
Laterz
"An expert is someone who has made all the mistakes in thier field" - Niels Bohr
|
|
|
|
|
|
Hi guys,
I need some expert advice here, if anyone knows more about this stuff  .
First, let's name two classes for clarity. cService and cUser.
The cService class uses a handle mechanism to give the cUser class a way to indicate which agreggate objects (within cService) are being referred to whenever it makes various function calls. That handle, as far as the cUser is concerned, is just a number which means nothing to the cUser. But internally to cService, this handle is really a pointer to a link element in a linked list.
The problem that arises is that sometimes the cUser may have an invalid handle because of multithreaded (de)synchronization, which it will pass to the cService. The cService class needs to check whether this handle is valid, so what I have devised is to cast the handle to some base class pointer, namely cDestructible*, and then try to do cast it to the templated link list element class pointer, say cListLink<cServiceAggregate>*.
This is done through a safe_dynamic_cast<>, which is basically a dynamic_cast<> wrapped in try catch handlers, as so:
<code>
// safe_dynamic_cast<> never throws an exception; it traps all exceptions, and
// returns a NULL pointer instead (and so the cast must be between two
// pointers).
template <class tDestType, class tSourceType>
tDestType
safe_dynamic_cast(tSourceType SourceObject)
{
tDestType Dest = NULL;
try
{
Dest = dynamic_cast<tDestType>(SourceObject);
}
catch(...)
{
// Failed; return NULL.
}
return Dest;
}
</code>
Now this mechanism seems to work fine. To further clarify (if anyone has been able to follow so far), we have cListLink, which is derived from cDestructible. cService has a list of cServiceAggregate objects which are referred to by the cUser via handles. When the cUser object calls a function of the cService class, the cService class validates the handle, trying to convert the handle to a pointer, as follows:
<code>
cListLink<cServiceAggregate>* Aggregate =
safe_dynamic_cast<cListLink<cServiceAggregate>*>
((cDestructible*)handle);
if(Aggregate)
{
// Do stuff with Aggregate here, as it is valid.
}
</code>
Now this system seems to work fine in debug mode, and has been working quite well for a while actually. But in release mode something falls apart. I get an access violation while in the dynamic_cast<> call, which is fine, but then my catch handler doesn't catch it---instead, everything just goes poop. The whole app crashes. Perhaps what I'm doing here is a no-no, but I don't know any other way I can do this.
C++ support RTTI, which I find is useless, because there is no way of determining if a given pointer is of a given type (only if it's MOST DERIVED type is that type). I can't just use a base class and a virtual function cause this doesn't help as we don't know if the handles are valid.
Anyone have any thoughts to this?
Cheers!
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
First of all, dynamic cast does not throw an exception, it just returns NULL. As far as I can see, there is no point in the safe dynamic cast class above.
I'm lost as to the rest of this - a handle is just a pointer to an object ? The point of RTTI is to be able to have an objerct of a base class and know which derived type it is pointing to. I didn't know if there were multiple levels of derivation it would fail if, for example, I asked if a CCheckListBox pointer was a CListBox pointer. That sounds wrong to me, I'll have to write some code to check.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Picture the daffodil. And while you do that, I'll be over here going through your stuff.
Picture a world without war, without hate. And I can picture us attacking that world, because they would never expect it.
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
I've done a lot of mucking around with this. Yes, the documentation SAYS that it should return NULL. However, dynamic_cast sometimes crashes when given an invalid pointer, and sometimes throws a bad_cast exception. Go figure!
And RTTI doesn't work with multiple levels of derivation. I've tried. 
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
swinefeaster wrote:
I've done a lot of mucking around with this. Yes, the documentation SAYS that it should return NULL. However, dynamic_cast sometimes crashes when given an invalid pointer, and sometimes throws a bad_cast exception. Go figure!
I'd love to see the code. I don't doubt you, but this has *never* happened to me and I use dynamic_cast constantly. MAybe we can find the reason you're getting such errors.
swinefeaster wrote:
And RTTI doesn't work with multiple levels of derivation. I've tried.
I haven't, but I'll have a play tonight ( not that I doubt you, I just like to prove stuff ). That is a little disappointing...
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Picture the daffodil. And while you do that, I'll be over here going through your stuff.
Picture a world without war, without hate. And I can picture us attacking that world, because they would never expect it.
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Here's a sample project that I made in a couple of minutes to illustrate how dynamic_cast<> does NOT work as advertised. Pretty disappointing....
BadDynamicCast.zip
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
It seems to me that you are accessing a pointer in an invalid range in the sample code that you submitted:
<br />
void CBadDynamicCastDlg::OnCrash() <br />
{<br />
CDialog* Crash = (CDialog*)2342;<br />
CAboutDlg* String = dynamic_cast< CAboutDlg* >(Crash);<br />
}<br />
Your pointer at 2342 or 0x926 is well below the 0x40000 range of protected memory. Try giving it a pointer that is above the 4 Meg boundary or NULL.
|
|
|
|
|
That's exactly the point! The documentation of dynamic_cast<> says at the bottom "The value of a failed cast to pointer type is the null pointer. A failed cast to reference type throws a bad_cast exception."
So, if the pointer is bad, it should ALWAYS return NULL. But no, we get a bad_cast exception sometimes, and even sometimes just making this call seems to screw up something pretty bad in the whole app and the whole thing crashes! Yikes.
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
What is inside the angle brackets of dynamic_cast? The html post stripped out this part - to stop this happening, click the "Display this message as-is (no HTML)" checkbox.
e.g. dynamic_cast<...>(val);
--
Andrew.
|
|
|
|
|
Done .
But I've since fixed the bug...
Swine
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
Ok, I'm not sure you've sorted this out, but here's my 2 cents.
The dynamic_cast actually has to examine the data at the other end of the pointer you feed it. It needs to look for the vtables of the type to which you want to cast the pointer. I'm guessing that the code inserted for the dynamic_cast doesn't do the dereference intelligently. So if you feed it a pointer that would normally dump core when you dereference it, it's still gonna yak.
The documentation should probably mention this, although perhaps the authors just assumed you'd be feeding it actual object pointers.
J
|
|
|
|
|
Yes, I would expect it to 'yak', but in a way that the catch(...) handler would just be invoked with an exception and everything should continue as normal, no? But it seems that a bad dynamic_cast<> also modifies memory somewhere, and really messes things up.
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
Another possible solution to your problem:
Use a map to track all valid handles in cService. When a handle is freed, remove the entry from the map. When a call is made which uses a handle, see if it exists in the map. If it does not, it is an invalid handle.
A numeric map should be pretty fast (just set the size of the hash table).
Just my 2 cents.
Matt Gullett
|
|
|
|
|
Actually that's exactly what I came up with after some more thought . But then I ran into a global / static object problem with this scheme. Check out my more Recent Post... I implemented the code as follows:
<br />
#pragma once<br />
<br />
#include "cMap.h"<br />
#include "cCriticalSection.h"<br />
<br />
<br />
class cParanoid : public cDestructible<br />
{<br />
public:<br />
cParanoid(void);<br />
virtual ~cParanoid(void);<br />
<br />
static cParanoid* GetParanoid(void* Pointer);<br />
<br />
private:<br />
static cMap<cParanoid*, cParanoid*, bool, bool> m_ParanoidMap;<br />
<br />
static cCriticalSection m_ParanoidSection;<br />
};<br />
<br />
cMap<cParanoid*, cParanoid*, bool, bool> cParanoid::m_ParanoidMap;<br />
<br />
cCriticalSection cParanoid::m_ParanoidSection;<br />
<br />
cParanoid::cParanoid(void)<br />
{<br />
m_ParanoidSection.Lock();<br />
{<br />
m_ParanoidMap[this] = true;<br />
}<br />
m_ParanoidSection.Unlock();<br />
}<br />
<br />
cParanoid::~cParanoid(void)<br />
{<br />
m_ParanoidSection.Lock();<br />
{<br />
if(!m_ParanoidMap.RemoveKey(this))<br />
{<br />
}<br />
}<br />
m_ParanoidSection.Unlock();<br />
}<br />
<br />
cParanoid* <br />
cParanoid::GetParanoid(void* Pointer)<br />
{<br />
cParanoid* Paranoid = NULL;<br />
<br />
m_ParanoidSection.Lock();<br />
{<br />
if(m_ParanoidMap.DoesKeyExist((cParanoid*)Pointer))<br />
{<br />
Pointer = (cParanoid*)Pointer;<br />
}<br />
}<br />
m_ParanoidSection.Unlock();<br />
<br />
return Paranoid;<br />
}<br />
The problem is that I get a pure virtual function called upon shutdown of the app. This is because CWinApp is a global, and the critical section and map of cParanoid get destoyed before CWinApp does, and there are some objects owned by CWinApp that are derived from cParanoid.
Any thoughts?
Thanks!
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
First thought,
if the objects owned by CWinApp are allocated on the heap (ie. new), then I would add a method to my CWinApp derived class something like "NotifyObjDelete(cParanoid* pValue)". In my CWinApp class, I would see if I own that object and set it to NULL.
I would call the NotifyObjectDelete from my objects destructor.
This is not a pretty solution, but might work depending on where you are in your development process.
I'll keep thinking.
Matt Gullett
(Sorry for the Anonymous, I am not at my PC right now.)
|
|
|
|
|
Thanks for the input... but unfortunately this won't do.
First off, the objects can't know anything about the CWinApp object, as they can be destroyed via a thread other than the main gui thread (and you're not supposed to access CWnd objects from other threads, and I believe this goes for CWinApp objects as well).
Second, the real nuts of the problem is that by the time the CWinApp destructor is invoked, the cParanoid static members have already been destroyed. This includes the critical section and the map of valid cParanoid pointers.
There's gotta be a way to specify which global objects get deleted in which order. I just don't know it...
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
Try adding code to your applications ExitInstance method to free the reference to these objects in your derived CWinApp object.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
