|
IceBerG71 wrote:
...the size of the programs grows a lot, from the initial 10k to abt 100k
Are you relating the growth directly to the inclusion of exception handling?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Yes, the size was a result of adding the excpetion blocks, maybe i use too extensive, every functions i use the exception to protect the codes in case there is any errors resulting in unforseen cases. initially, it helps me in debugging, after solving the bugs, so far, the exception was never resulted but frankly speaking, it is hard to predict what user can do to it since there is user entry portion.
I checked MS website, it was indicated that the __try __ except is WIN32 exception handling. and they also indicated not all cases can be captured by the __try block.
|
|
|
|
|
If size is critical, don't use exceptions for careless programming, only to actually catch critical errors outside your control. You could also drop C++ exception handling entirely and use only Win32 structured exception handling.
(My opinion may be unpopular, but C++ exception handling itself does not ensure a reliable program. It helps clean up the stack, but in the end, is just another error handling mechanism. I use exceptions very sparingly; mainly where other error handling techniques grow more cumbersome than if I had used exceptions.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
FWIW '__try/__except/__finally' aren't C++ exception handling, it's (AFAIK) an MS enhancement to their C and C++ compilers that allows code to be generated for Win32 Structured Exception Handling. In the Windows world C++ exceptions are built on top of this.
This obviously doesn't help you, but getting the terminology right cannot hurt...
Paul
|
|
|
|
|
I have a libray which sets up shared memory and an event to
schedule some processing (display data, quite larger) in a GUI (a separate thread in the GUI will process this event).
All works fine if I use timers to do the display of the data, however if I opt for Events then the Shared Memory pointer 'm_pMsg' goes invalid following the first event.
So Shared Memory does not work with Events - Am I missing something
Could someone have a good at the code sections below and see if this scheme is correct
In the Library (Loaded DLL)
m_hMap = ::CreateFileMapping((HANDLE)0xFFFFFFFF,NULL,PAGE_READWRITE,0,
sizeof(TSharedMemory),
"CSLSharedMem");
// Obtain a pointer from the handle to file mapping object
m_pMsg = (TSharedMemory*)::MapViewOfFile(m_hMap,FILE_MAP_WRITE,0,0,sizeof(TSharedMemory));
// Set up an event for the GUI to process the Display Text
hGlobalWriteEvent = CreateEvent(NULL, // no security attributes
TRUE, // manual-reset event
FALSE, // initial state is signaled
"CSLDisplayData" // object name
);
// Signal GUI to process this request
::SetEvent(hGlobalWriteEvent);
Now in the GUI (Main)
// Try to create file mapping object (assume that this is the server)
m_hMap = ::CreateFileMapping((HANDLE)0xFFFFFFFF,NULL,PAGE_READWRITE,0,
sizeof(TSharedMemory),
"CSLSharedMem");
// Check if file mapping object already exists. If it does, then this is a
// client and in this case open existing file mapping object. Client also
// needs to create a mutex object to synchronize access to the server
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
m_hMap = ::OpenFileMapping(FILE_MAP_WRITE,FALSE,"CSLSharedMem");
m_strOutput+= "File Already Exists - This is the Client " + crlf;
SetDlgItemText(IDC_OUTPUT, m_strOutput);
UpdateData();
}
else
{
MessageBox("File Mappings Hove Not Been Setup - Check WHLLIB.DLL");
m_strOutput+= "Warning - This is the Server " + crlf;
SetDlgItemText(IDC_OUTPUT, m_strOutput);
UpdateData();
}
// Obtain a pointer from the handle to file mapping object
m_pMsg = (TSharedMemory*)::MapViewOfFile(m_hMap,FILE_MAP_WRITE,0,0,sizeof(TSharedMemory));
In the GUI Thread
UINT CTestGUI1Dlg::DisplayTextThread(LPVOID param)
{
/* This is the thread function for the Display Data. The structure contains a stop flag and the 'this'
pointer for access to the dialog properties. */
DisplayThreadData* ThreadData = (DisplayThreadData*)param;
CTestGUI1Dlg* pxDlg = (CTestGUI1Dlg*) ThreadData->_this; // (CMyDialog*) pxDlg = (CMyDialog*) pParam;
// Set up an event for the GUI to process the Display Text
hGlobalWriteEvent = CreateEvent(NULL, // no security attributes
TRUE, // manual-reset event
FALSE, // initial state is signaled
"CSLDisplayData" // object name
);
while(!ThreadData->stopFlag)
{
if (::WaitForSingleObject(hGlobalWriteEvent, INFINITE) == WAIT_OBJECT_0)
{
// AfxMessageBox("Event Fired");
pxDlg->UpdateOutput();
}
}
return 0;
}
Help
|
|
|
|
|
Global events and shared memory have no relationship, apart from using the global namespace, etc..
You scheme is fundamentally valid, though, as you stated, you may want to add a mutex so the shared memory can be locked.
I don't like how you pass the pointer of the dlg into the thread; it seems awfully convoluted. Why not just pass the this pointer as the param?
The second potential problem is pxDlg->UpdateOutput(). This is the most likely candidate for a memory overwrite of your m_pMsg pointer. (The shared memory is very likely still there, (Verify with this utility: http://www.sysinternals.com/ntw2k/freeware/procexp.shtml[^])
A few other concern: You may be handling CTestGUI1Dlg incorrectly. You should use PostThreadMessage to do more than trivial things in a CWnd derived object from a secondary thread.
In your loop, you don't check stopFlag immediately upon the wait being satisfied. When shutting down, this could cause problems if the dialog is destructed earlier than hGlobalWriteEvent is set.
The event is a manual event, but isn't being reset.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Thanks for your comments on the code.
All I am trying to do is have an Edit Box (Multi-line, vertical scroll) display text posted via a call to DLL. The thread handles the Event from the DLL but needed access to the dialogs classes.
I don't like how you pass the pointer of the dlg into the thread; it seems awfully convoluted. Why not just pass the this pointer as the param?
That why I pass in the dialog pointer (this) and the stop flag.
The structure is as follows:-
// For Display Text Thread
typedef struct
{
bool stopFlag; // Set if some error occured during the process or want to terminate
CTestGUI1Dlg* _this;
}DisplayThreadData;
The second potential problem is pxDlg->UpdateOutput(). This is the most likely candidate for a memory overwrite of your m_pMsg pointer.
Whats the alternative, as if I comment this call out, program does not crash (but does not display the text. I think you are right, this is where the problem is!!!
But what to do?
A few other concern: You may be handling CTestGUI1Dlg incorrectly. You should use PostThreadMessage to do more than trivial things in a CWnd derived object from a secondary thread.
Sorry you have passed the limit of my knowledge.
I was using a timer to process the text display, but had to slow things down (on both size) to be sure of not losing data.
Was advised that reacting to events would be better.
But ended up with a different problem.
Have now set Event to Auto reset and sorted out the terminate logic.
Sweep123 working from home.
grahamfff
|
|
|
|
|
Grahamfff wrote:
That why I pass in the dialog pointer (this) and the stop flag.
My mistake; based on past experience I assumed you were passing some convoluted thing.
Grahamfff wrote:
A few other concern: You may be handling CTestGUI1Dlg incorrectly. You should use PostThreadMessage to do more than trivial things in a CWnd derived object from a secondary thread.
Sorry you have passed the limit of my knowledge.
In MFC, you aren't supposed to call any control objects owned by one thread from another. You can do it, but it can cause problems [usually reentrancy problems.] The proscribed solution is to use PostThreadMessage with the handle of the window in question, in this case the dialog box, with a USER message or even a "fake" valid message. (Try creating a fake WM_TIMER message.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
such as tips, compiler setting, shortcut key...
|
|
|
|
|
|
|
Hi, I have a question.
Is there any way to play a MJPEG file with Windows Media Player?
Thanks
|
|
|
|
|
yes. but you'll need an MJPEG codec to do it. there are many commercial codecs available... don't know of any free ones...
Cleek | Jewelry | ClickPic | ThumbNailer
|
|
|
|
|
Dear Expert,
I'm a mschart control newbie. Here are 3 Questions needed your help.
(below is supposing to use this contorl in VB , you can also use it in VC, or other windows program tools capable of using this ActiveX controls, the encountered problem is same)
Q1: When I set *.ChartType=VtChChartType2dXY, How can I set X-asis Label to
my own expected string instead of Xas automatic generated by
itself.(Such as datetime instead of "0 1 2 3 ...")
Q2: Both when *.ChartType=VtChChartType2dXY or VtChChartType2dLine,
and when Xas Lable string is too long , How can I display it in Multi-line
Q3: When *.ChartType=VtChChartType2dLine , and after I set xasis.tick.style=...Inside,
& xasis.tick.length=200, it does not take effect, nothing changes , and what I expected to occur does not occur
In sum, What I want to do is by using mschart (must , cant use any other 3rd party controls),
set xasis infos(such as label , tick style, length) customarily by my expected format
Thanks in advance , Expecting your answer!
Allen, Homer
|
|
|
|
|
Hi!! I need some help here.
How to convert an integer variable to string so that the string and the variable can be concatenated. The string will be displayed in the edit control.
Thanks
jazzlycool
|
|
|
|
|
CString str;
str.Format("%d", intValue);
char acBuffer[16] = {0};
sprintf(acBuffer, "%d", intValue);
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
Without using MFC:
int Number = 178;<br />
char szString[50];<br />
<br />
wsprintf(szString,"%d",Number);
or
itoa(Number,szString,10); /*gives the string in decimal : "178"*/
or
itoa(Number,szString,2); /*gives the string in binary : "10110010"*/
~Bikram~
|
|
|
|
|
Thanks for helping me.
jazzlycool
|
|
|
|
|
CString my_string;
int my_int = 54;
my_string.Format("The value is: %d", my_int);
|
|
|
|
|
is there any (system) function can test memory pointer to know combination of bits there is real (double, float) value?
something like this
if(isValidDoubleValue(dptr))
dvalue = 0.0;
else
dvalue = *dptr; //always no exception crash here
what will not crash
(all i found (like _isnan) expect given bit combination represents valid state and crashes getting invalid one)
thanks
|
|
|
|
|
Check IsBadReadPtr to guaranty that you have read access to the memory pointed by dptr
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
yes, but it does not guarantee will not crash next
doublevalue = *ptr;
|
|
|
|
|
If you have read access, it wont crash
will it?
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
sometimes will
_FPE_INVALID
|
|
|
|
|
After gaining read access, check for Floating point exceptions
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
