|
KellyR wrote: It's horrible.
Heh - it's painful to think about
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
KellyR wrote: Now I'm working on an MFC app (using VC++ .NET 2005) and it seems to crash when I try to free the memory
Could it be that you changed a to point to a different address? For example:
char *a = new char[100];
a = a + 1;
a = "Hello";
delete [] a; Or that free() does not go with new ?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Use square brackets when allocating arrays with new , not round ones: it looks like you allocating a single char initialised to ASCII 100, then treating it as an array. This is a buffer overrun and you're probably corrupting the stack.
If you use new match it with a delete . If you use new ??[] match it with a delete [] . If you use malloc match it with a free . Don't mix and match.
Steve
|
|
|
|
|
|
There's also the problem that
char *a = new char(100); does not allocate an array. It allocates one char and initializes it to 100. You want
char *a = new char[100];
|
|
|
|
|
I am using Ultimate TCP/IP to ping an address. worked great until I put it into a seperate thread. I believe I have the pointers right to execute the class, but when the parent class gets the call from the return it is always OnTimout.
I must be doing something stupid here....
void CBinDlg::StartPinger(void)
{
CWinThread* pWThread = AfxBeginThread(PingAddress, this);
}
UINT PingAddress(LPVOID pParam)
{
CBinDlg* pDlg = (CBinDlg*)pParam;
pDlg->icmp.SetDoLookup(false);
pDlg->icmp.SetMaxTimeOuts(1);
pDlg->icmp.Ping( "10.0.2.60" , 1500, 32, 2);
return 0;
}
|
|
|
|
|
I don't know anything about Ultimate TCP/IP but you've passed a pointer to a dialog (based on the class name) to a worker thread. Worker threads don't have message pumps so your pDlg is not going to do anything.
Judy
|
|
|
|
|
Well phooey! back to the drawing board.
Thank you
|
|
|
|
|
Rhymhoont wrote: pDlg->icmp.SetDoLookup(false);
pDlg->icmp.SetMaxTimeOuts(1);
pDlg->icmp.Ping( "10.0.2.60" , 1500, 32, 2);
You need to put these three statements back in the primary thread (since they interact with the UI) and change PingAddress() to:
UINT PingAddress( LPVOID pParam )
{
CBinDlg *pDlg = (CBinDlg *) pParam;
return pDlg->PingAddress();
}
UINT CBinDlg::PingAddress( void )
{
PostMessage(some_user_defined_message);
return 0;
}
LRESULT CBinDlg::OnPostedMessage( WPARAM, LPARAM )
{
icmp.SetDoLookup(false);
icmp.SetMaxTimeOuts(1);
icmp.Ping("10.0.2.60" , 1500, 32, 2);
return 0;
}
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Simpler still is to call the PostMessage from inside the thread function
UINT PingAddress( LPVOID pParam )
{
CBinDlg *pDlg = (CBinDlg *) pParam;
pDlg->PostMessage(some_user_defined_message);
}
void CBinDlg::OnPostedMessage( WPARAM, LPARAM )
{
icmp.SetDoLookup(false);
icmp.SetMaxTimeOuts(1);
icmp.Ping("10.0.2.60" , 1500, 32, 2);
|
|
|
|
|
There appears to be two possible sorts of behaviour for selecting an item in a drop down combobox list:
1: Click once to get the list to drop down, then click on the selection.
2: Click and hold to get the list to drop down, move to selection, release to select it.
The default behaviour of comboboxes in MFC programs appears to be type 1. Is there any way to make them into type 2?
|
|
|
|
|
Wxffles wrote: There appears to be two possible sorts of behaviour for selecting an item in a drop down combobox list:
2: Click and hold to get the list to drop down, move to selection, release to select it.
How are you verifying this second method? I just opened one of my MFC apps, and the combobox does both (with no special coding on my part).
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Upon further investigation I've found that it works just as you say (and just as I want) when you use the old style common controls (version 4.7?). But when you use the new XP style (version 6.0), the behaviour changes. (And the extended user interface doesn't help). So I guess my question becomes, how do make them look new and work like they did in previous versions?
|
|
|
|
|
Wxffles wrote: There appears to be two possible sorts of behaviour for selecting an item in a drop down combobox list:
Nope, but that's a good guess. Continue guessing if you prefer, or the alternative I like to use to eliminate as much guessing as possible is to refer to the documentation[^]
The Extended User InterfaceDrop-down combo boxes and drop-down list boxes support an alternative keyboard interface called the extended user interface. By default, the F4 key opens or closes the list, and the DOWN ARROW changes the current selection. In a combo box with the extended user interface, however, the F4 key is disabled and pressing the DOWN ARROW key opens the drop-down list. In addition, the mouse wheel, which normally scrolls through the items in the list, does not have any function when the extended UI is set. To select the user interface for a combo box, an application can send the CB_SETEXTENDEDUI message to the combo box. A TRUE value for the wParam parameter enables the extended user interface; a FALSE value sets the default user interface. To determine whether a combo box uses the extended user interface, an application can send the CB_GETEXTENDEDUI message to the combo box.
|
|
|
|
|
I have a MFC application where I used to have menu items enabled /disabled whenever I want to. Later I added another menu item and tried to do the same with it. It works fine when I run the application from debug folder and it doesn't update that menu item running in release mode. This happens only to this new item that I added while the rest work fine as they do before.
Any suggestions are appreciated...
thanks,
PKNT
|
|
|
|
|
any code inside ASSERT ?
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.
|
|
|
|
|
I am not sure what's happening, but in release mode whenever I run it from MS Visual C++ interface that menu item doesnt work as it should be, but when I run the application directly from release folder of the project it runs fine.
PKNT
|
|
|
|
|
How can I change the state of toolbar buttons at runtime. I tried using OnUpdateUI methods and it seems not to do what it is supposed to do. Is there any other way to do this?? I would like to enable or disable some toolbar buttons based upon user selection from menu.
thanks,
PKNT
|
|
|
|
|
I am over my head again with the implementation of this "class" / structure.
Could someone please explain to me why the following code does what it does?
CRuntimeClass *pView_Tab = pVisualObject_tab->m_pRuntimeClass;
This code shows "normal " CRuntimeClass members of class CMyTabView.
CMyTabView *pTab = (CMyTabView*) pVisualObject_tab->m_pRuntimeClass;
pTab->AddTab("TEST");
And this one has same pointer and show the CMyTabView class and lets me run the AddTab of CMyTabView.
I have a debug trace but cannot paste it here
until I figure out how to copy it from IDE!
I need to run the AddTab function and like to know why these two lines have same pointer with “different results”.
I don’t think my code is right since it needs a cast to make it work. I think it defeats the intent of access to “runtime class”.
Thanks for you help.
Cheers
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: CMyTabView *pTab = (CMyTabView*) pVisualObject_tab->m_pRuntimeClass;
pTab->AddTab("TEST");
I'm not sure I like that cast. Where did you get that code from?
What is pVisualObject_tab?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I don't like it either - the cast.
pVisualObject_tab is plain C++ class - not derived from anything!
(Maybe I should try to derive it from CObject - any thoughts on that?)
And the m_pRuntimeClass is CRuntimeClass *m_pRuntimeClass member of it.
I am really confused with this class / structure - it points to what?
It is "defined" as RUNTIME_CLASS(CMyTabView) but it does not let me access the class functions.
Thanks for your help Mark.
|
|
|
|
|
Hmm, well you can cast pointers to other types but that doesn't change what the
pointer really points to. Just because the compiler lets you do it doesn't make it right.
The fact that you needed a cast should always be a warning sign.
Maybe back up a bit - what are you wanting or trying to do?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
My basic problem is to understand how to access the runtime class using the CRuntimeClass structure.
I'll go back to books for now.
Thanks Vaclav
|
|
|
|
|
Vaclav_Sal wrote: My basic problem is to understand how to access the runtime class
I'm not convinced. I think your basic problem is you don't know "why" you think you need to access the runtime class. I think you are assuming you need to access the runtime class. You may be right, you may be wrong, I don't know.
|
|
|
|
|
Here's a good place to start: CRuntimeClass Structure[^]
Maybe led mike linked to that as well - I'm too lazy to click his links
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|