|
Hi! Your post does not show <s and >s properly, next time you can check the "Display this message as-is (no HTML)" option (just above the edit area). Nevertheless, I've managed to read it through the source code of the page.
As for the problem, the correct syntax for calling the member function is
pMainFrame->template PlugNewModule<RobCtrlPage>(); Try it (if you please ) and tell us if it worked. Even so, it's possible that you experience some problems (due to a bug in VC++) resulting in the function being called for a type different to what you specified! If so, please report it back, the thing could possibly be workarounded.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
No, it doesn't.
I've got ...
warning C4042: 'identifier' : has bad storage class
error C2951: template declarations are only permitted at global or namespace scope
-----
Mit freundlichen Grüssen/Best Regards/Un cordial saludo.
Ing. José Manuel Hostalet Wandosell, Fraunhofer IPA, Abt.323/Robotersysteme
Nobelstrasse 12, D-70569 Stuttgart (Germany)
mailto:jose.hostalet@ipa.fhg.de, http://www.ipa.fhg.de
|
|
|
|
|
I would like some help. I need source code that will recursively search the registry and delete text found. It would need to work on 95/98/NT/XP/2000. Any ideas? Any help is appreciated.
Thank You,
Derek
|
|
|
|
|
I'm looking to return a list (perhaps in a list box) of all keys (ALL TEXT) that were found. If that Text appears anywhere in registry I want it added to my list. Then I can select/deselect what I wish and then delete the selected items. Allow someone to highlight and delete specific ones.
|
|
|
|
|
In my MFC application running on Win2k, the following code
fails in a worker thread, but succeeds in the main thread.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
servaddr.sin_family = AF_INET;
servaddr.sin_port = htons(PORT);
servaddr.sin_addr.S_addr = IP;
int ret = connect(sockfd, (struct sockaddr *)
&servaddr, sizeof(servaddr));
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
In the worker thread, the error is always WSAETIMEDOUT,
never succeeds! But the same code in an applicaiton running
on WinCE works well! What's wrong with it?
Thanks a lot!
|
|
|
|
|
I believe you need to use a UI type thread instead of a worker thread because the worker thread doesn't have a message pump..
Rob
|
|
|
|
|
This is the array for the status bar:
static UINT nIndicators[] = { ID_SEPARATOR,
ID_INDICATOR_LINE,
ID_INDICATOR_CAPS,
ID_INDICATOR_NUM
};
==============================
and this is the function setting the indicators:
m_wndStatusBar.SetIndicators(nIndicators, 4);
==============================
Still, on the status bar, everything else shows up except "CAPS". Does anyone have any idea why?
Thanks! I appreciate it.
William
|
|
|
|
|
No need to reply to this concern. I've already found out the reason.
Thanks.
William
|
|
|
|
|
Sorry for the repost but after working with this almost all night I am still stuck --
I am having a problem using print and printpreview in a FormView.
If I build using MFC as a shared dll, all works as it should.
If I build using MFC as a static library, I get an error when the print function tries to create the dialog to show print status. Apparently when
Create(CPrintingDialog::IDD, pParent);
gets called in the CPrintingDialog contructor,
if (!_AfxCheckDialogTemplate(lpszTemplateName, FALSE))<br />
{<br />
ASSERT(FALSE);
PostNcDestroy();
return FALSE;<br />
}
in CDialog::Create fails because there isn't a valid document template name. Is this the document template name of my form view or one created by MFC for the print dialog? How do I make sure it gets set? I need to compile using MFC as a static library due to installation on other Windows versions.
Ed
|
|
|
|
|
this might help..
Link[^]
|
|
|
|
|
Is it save to realloc a newed buffer, or do one have to use malloc?
<br />
LPBYTE pBuffer = new BYTE[1024];<br />
pBuffer = realloc(pBuffer,2048);<br />
delete[] pBuffer;<br />
<br />
|
|
|
|
|
I believe the result is undefined so you should try to avoid code like this. Might work until one day... probably the day when you are showing your project to a potential customer
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
|
|
|
|
|
It is undefined when you use realloc on a buffer that you allocated with new.
Probably the best way to do this type of operation is to use a vector instead:
<br />
std::vector<BYTE> myBuffer(1024);
myBuffer.resize(2048);
<br />
Best regards,
John
|
|
|
|
|
if you step into the new-handler, it actually calls malloc.
Do you consider that when stating that it's undefined?
Thank you for your answer.
The reason that I ask, is that I'm writing a specialized buffer, and thus cannot use std::vector.
I am using malloc, but just out of curiosity.
|
|
|
|
|
You can not mix and match new/delete with malloc/free/realloc. Just because version of the compiler implemented it using malloc means that the same will work for a different version.
The standard specifically states that delete can only be used with new.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Although the current compiler you are using calls malloc as part of its implementation of the new-handler, this is not specified by the C++ standard, and should not be relied on. Another compiler (or a more recent version of the compiler) can change the implementation so that malloc is not called. The result from calling realloc on a buffer allocated with new is undefined. While it may work with this version of the compiler when allocating a POD, it is not a good practice to rely upon an implementation detail that you have no control over. If you decide that realloc is the only way to go, don't use new for the original allocation - just use malloc.
You should be able to use a vector anywhere that you use a raw allocated buffer. What are you trying to do that you don't think will work with a vector?
|
|
|
|
|
Hi,
Looks like I'm having a brain fart this morning and can't remember how to cancel the closing of a property sheet.
I have two property pages, and I validate some settings in the CMyPropPage1::OnOk() handler. If the settings are invalid, I display a msgbox to the user and want to leave the property sheet displayed. However, it's closing after the user closes the msgbox! When the settings are invalid, I simply return from the handler (which appears to be wrong...). So, what do I have to do to keep it displayed??
Thanks!
Chris
"No one goes to hell because of their sin, but because of rejecting God's method of salvation: His Son's life for yours..."
"It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams
|
|
|
|
|
Well when OnOK is called in the PropertySheet all the PropertyPageses that have been activated get their OnOK called. That means all the pages have been validated; therefor, no matter what the return is from OnOK on the Sheet it will close. Al least that is my experiance. It may be totally incorrect but it is what I tell myself to feel better.
So what do you do? In all my PropertySheets I validate at the Page level. That way if a page fails then I show message and return there.
Hope it helps.
***********************
Tony Fontenot
Recreational Solutions
tony@recsolutions.com
***********************
|
|
|
|
|
I'm writing an application with heavy mt.
the app runs for about 20 seconds, and then crashes in a malloc call, either through new or CString operator <<
I HAVE used the mt runtime, and it doesn't help.
the linker complained about libc conflicts, so I exluded it with /NODEFAULTLIB
Is it dangerous to load an mfc dll, from an atl application?
Anyone with a hint?
|
|
|
|
|
No. But it is dangerous to have buggy code that trashes memory causing malloc to break.
You software is buggy. Look for buffer overruns or accessing memory that has been freed.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Would I be unreasable if I said You where rude?
Just assuming my "buggy" code being a reason, seems - to me - like a habit of writing bad code. (?)
If you have nothing better to write...
|
|
|
|
|
No, he was not rude, he was right.
Don't take it personally: everyone writes buggy code. Good professionals find bugs and fix them before shipping to users.
And take his advice, it's not easy to write thread safe code, the number of race conditions in the simplest code is impressive and a buffer overrun is easy.
Just a sample: try doing a strcat on two threads at the same time and you'll have a buffer overrun.
Your incessant rantings indicate you have a brain the size of a pea, and the mental capacity of a bag of hammers. - John Simmons
|
|
|
|
|
Well, I was being a little rude. But time and time again I see people blame malloc or some other silly thing for their own bugs.
I always look at the compiler/library last as the source of my problems. In 15 years, I think I have found only 4 compiler/library bugs. The 999,985 other bugs were all my fault. And even that number is probably a gross under-estimation.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
But time and time again I see people blame malloc or some other silly thing for their own bugs.
The same people that never post a code sample demonstrating the bug.
I know what you feel like, I had a really BIG discussion (may I call it fight?) with a fellow programmer that insisted he wouldn't even look at his code, because the bug was in the COM+ thread pool. "The proof? Use the component as a non-pooled component and everything works ok".
Well, looking 5 minutes at his code I found the bug.
Your incessant rantings indicate you have a brain the size of a pea, and the mental capacity of a bag of hammers. - John Simmons
|
|
|
|
|
I have always had the philosophy that between my code and the compiler, only my code can be modified. So there is little point looking at the compiler. Even in the VERY rare case of a compiler problem, your only choice is to modify your code to avoid the problem. :/
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|