|
CButton* m_Button;
m_Button->Create("Button1",WS_VISIBLE|WS_CHILD|WS_TABSTOP,rect,this,1111);
You defined a pointer to a CButton object but you have not allocated space for it. The pointer points to some memory space for which you do not own and is not a CButton object. So when you call Create on the m_Button pointer it will crash because you are accessing an address space for which you do not own.
Add "= new CButton()" to the end of your CButton* m_Button declaration like so:
CButton* m_Button = new CButton();
Then you can call Create on the pointer.
Regards,
-Erik
|
|
|
|
|
Dear Eric,
I use the declaration u tell me like so :
CButton* m_Button = new CButton();
and happen an complie error like so :
error C2258: illegal pure syntax, must be '= 0'
error C2252: 'm_Button' : pure specifier can only be specified for functions
why, and how to fix it.
Regards,
Vistac
|
|
|
|
|
It sounds like you are trying to instantiate your m_Button member in an abstract class.
Regards,
-Erik
|
|
|
|
|
Hi,
My software needs some drawing tools, which need to be drawn transparently over a bitmap. The tools include:
-> Line, freehand, text, etc.
-> A 'cup to disc' tool. Essentially this is two circles, one inside the other. They are dragged by the user to a particular spot on the image (which is why they have to be transparent) and the software calculates the ratio of the area of one circle to the next.
Now being my naive self, I thought "Jee, if i made the cup-to-disc tool a windowless activex control i won't have any messy message handling in my view's mouse message classes, because the activex control will receive all the messages". You'll probably notice that the cuptodisc tool not only needs resizing but also repositioning in the container. Well I got all working, except:
-> After about 30seconds of moving the tool around, I start getting first-chance exceptions and finally an unhandled exception which bombs the software. I've since found out this could have something to do with a bug in MFC (Q192942) which causes a stack overflow... Great
-> In my CCupToDiscCtrl::OnLButtonUp() function if the tool is being moved I call:
<br />
myRect.SetRect(point.x, point.y, point.x + 20, point.y + 20); <br />
if (!SetRectInContainer(&myRect))
TRACE("Fail set rect!\n");<br />
But I might click on the tool and drag it to the bottom-right of the screen, and it ends up in the top-left! Or I drag it down and it goes up! And resizes! Note that in my OnDraw I only draw within the confines of rcBounds. Its driving me crazy...
So the point of all this is:
1/ Do I swallow my pride and dump this whole windowless ActiveX thing? It works well if it wasn't for the damn crashing and the fact it doesn't go where I want.
2/ What other options do I have to implement this? Assuming the number of tools may grow to 12 or more, what's the best way to lay them out so my windows message handlers and View's OnDraw stays relatively clean? I saw the JTDraw example on Codeguru and it seemed to be getting too noodle like for me (not quite spaghetti  . Is making the View a OLE container going to help?
Thanks for any help. Sorry for my ramblings... but I've run out of options 
|
|
|
|
|
Only you can answer question one, but I'd suggest that whatever you do, you'll find there are hurdles. If it were me, I would stick with it, on the basis that I refuse to be beaten by a machine. If it was for work and it was taking too long, I'd do something else and fix it in my time, as a matter of pride. However, I have some serious issues, so take this as a comment on my state of mind rather than advice...
As for question two, in my paint program I created a virtual base class for drawing tools, and put in functions for every message that a tool is likely to use ( OnLButtonDown, OnMouseMove, OnDraw, OnPrepareDC, etc ) and then put the appropriate code in each derived class. So my view class looks like this:
CGrausPaintView::OnMouseMove(CPoint point, etc)
{
PaintTool->OnMouseMove(point, etc);
}
Much cleaner and easier to extend.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
|
look at following code:
STDMETHODIMP CADOTier::OpenRecordset(VARIANT query)
{
VARIANT v;
V_VT(&v) = VT_DISPATCH;
V_DISPATCH(&v) = (IDispatch*) m_connection;
// Need the AddRef() as VariantClear() calls Release(), unless fAddRef
// false indicates we're taking ownership
//
V_DISPATCH(&v)->AddRef();
return m_recordset->Open(query, v, adOpenDynamic, adLockOptimistic, adCmdText);
}
It is a method Implementation of a COM object. It uses another COM object method "open" to open a recordset with a parameter of IDispatch interface type passed--v.
But who can tell me why I must call V_DISPATCH(&v)->AddRef() to increase reference count and where the reference count will decreased?
(VariantClear ? But not find here)
TKS
|
|
|
|
|
I have an array, containing a CStringList and another CArray. Is there an easy way to copy a CStringList or another CArray short of manually iterating through each element, copying it over each time???
// in .cpp file somewhere...
CArray <ctable, ctable&="">* m_parrTables;
// in .h file
class CTable : public CObject
{
public:
CString m_strTable;
CStringList m_lstParents;
BOOL m_bProcessed;
CArray <crule, crule&="">* m_parrRules;
CTable& operator=(const CTable& a)
{
m_strTable = a.m_strTable;
m_lstParents = a.m_lstParents; // ?????
m_bProcessed = a.m_bProcessed;
m_parrRules = a.m_parrRules; // ?????
return *this;
}
}
|
|
|
|
|
A CStringList is exactly that: a list. As a result, there is no way of copying the elements apart from iterating through them.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I want to change the text that the clock displays. I've subclassed the window and intercepted the WM_SETTEXT message, but it only changes the windows text in Spy ++, not the displayed text.  How do I do this?
Greg J. Hedlund
SuperStar
|
|
|
|
|
I am using this function to get the serial number of a hard drive. However, it doesn't work when running under Win 9x and trying to get the serial no. of an NTFS partition (e.g. Win 9x workstation trying to get serial no. of NT server partition). It always returns 0. Is there any way around this?
|
|
|
|
|
I want my application which is written with VC to support Multiple language. i did the follow:
first, i put resource to dlls, each dll is for one language,
then,
CMyApp::InitInstance()
{
int nLang = detect_which_language_to_use();
CString strLang;
strLang.Format("Lang%d.dll", nLang);
//load the resource
HINSTANCE hInstance = ::LoadLibrary(LPCTSTR(strLang));
ASSERT(hInstance);
::AfxSetResourceHandle(hInstance);
}
it works. but now i want to let the user choose the language, that is, i add a menu in my program, user can choose the language he want by clicking the menu.
how can i do these? thanks.
hs
|
|
|
|
|
Hello, the codegurus around the world. 
Before you make the multi-language application, you had better consider the followings.
For example,
1) English Windows 9x can't show Japanese corretly.
2) Some Japanese user can't understand English.
So, what language will you use for the menu item? English??
At the menu, we can use CDialog class with the radio button something like that
for the user to select the language....
But before that, you must solve some problems....
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
i change the resource(AfxSetResourceHandle) by clicking a menu item, then i show new a dialog,my program use the dialog accord to my choice, but the GUIs which had been showed was not effected.
|
|
|
|
|
Hello, the codegurus around the world.
Actually, I don't understand your problem very well,
but if I guess....
After the code passes the point of AfxSetResourceHandle, the application can't change
the resouce DLL. (However, we may use FindResouce API function for each resouce ID..?)
So, before AfxResourceHandle is called, we must choose which resouce DLL will be used.
As a result,
CMyDialog dlg (AfxGetMainWnd()); // for the bug of Windows ME.
dlg.DoModal(); // with the radio button ?
// Get the data which the user selects as the language from the dialog;
if (sLang == EN)...
HINSTANCE hInst = Loadlibrary (someDLL);
if (hInst)
AfxResourceHandle(hInst);
......
// After this, we can't change resouce DLL.
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
actually masaaki you could put a menu of bitmaps of flags to select the language you wanted as they do on many web sites
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hello, the codegurus around the world.
lauren:
I am already working for the other part of bitmaps for the international language.
However, if we use the international language by bitmap format,
we had better be careful about the appearance of this.
For example, like the menu,
1) Japanese (normal letter on Dialog) - (Japanese) by bitmap.
This bitmap had better have the same color of the background like the dialog
as well as the same size of the font as the normal letter of dialog.
As a result, we work more than we expect ....
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
I began writing a program on one of my computers the other day, and I decided to work on it on different computer later on...I zipped the source code files, and moved them to my other computer...now that I have unzipped them, and resumed working on my program, I have no problems compiling, or anything like that, but instead the menu that pops up when trying to access a function with the dot operator will not show. Any ideas? When I use the -> operator, a menu comes up, but not with the . operator.
Thanks again.
|
|
|
|
|
Get Visual Assist. ( www.wholetomato.com ). Not an immediate answer to your question, but VA extends these menus, autocompletes, case corrects, etc, etc, etc. It rules.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Apparently my compiler (it's VC6.0) has decided that try and the following catch block are not needed in release mode, and I have not the slightest clue as to why. For example, if I create a new dialog app and put this code in it:
void CJunkDlg::OnButton1()
{
char *p = 0;
try
{ *p = '\0'; }
catch(...){ AfxMessageBox("!"); }
}
and compile in debug.. click.. "!". That's expected behavior!
Rebuild it in release and I get an access violation as if the try/catch wasn't there.
I've checked the compiler settings. I have /GX. That's the default for a new project after all!
If I put the warning level on 4 and rebuild, I get the warning C4702: unreachable code when in release, and nothing in debug. If I disable optimizations in release, the warnings evaporate and the catch(...) works as advertised. For obvious reasons, that's not the solution I'm looking for.
Here's a snippet of the assembly generated in release with full optimization (it looks bizarre to me):
00401494 nop
00401495 nop
00401496 nop
00401497 nop
00401498 nop
00401499 nop
0040149A nop
0040149B nop
0040149C nop
0040149D nop
0040149E nop
0040149F nop
004014A0 mov byte ptr ds:[0],0 <<< *p = '\0';
004014A7 ret
004014A8 nop
004014A9 nop
004014AA nop
004014AB nop
004014AC nop
004014AD nop
004014AE nop
004014AF nop
What's with all the nop's?
I really hope someone out there has seen this before. Thanks much if you can help!
Matt
|
|
|
|
|
Interesting stuff - the compiler seems to be changing the call format of the function, optimizing away the stack operations, which disables the exception framework.
I made a small change to your code, and added optimization pragmas - this works now in release:
#pragma optimize( "", off )
void CAboutDlg::OnButton1()
{
try
{
_asm int 5;
}
catch(...)
{
AfxMessageBox("!");
}
}
#pragma optimize( "", on )
I agree with you that the compiler is being a bit aggressive with its optimizations. I can understand the compiler removing code like int x=0; if x is not referenced again, but not this.
In looking at the dissassembly you'll see that the compiler is removing the stack overhead - thats why we get such a minimal asm output - and also why the try catch is ignored - if there's no stack entry/exit, there's no room for the exception framework.
Here's the dissassembly window in release without the pragmas:
163: void CAboutDlg::OnButton1()
164: {
004016A0 int 5
165:
166:
167: try
168: {
169: _asm int 5;
170: }
171: catch(...)
172: {
173: AfxMessageBox("!");
174: }
175:
176:
177: }
004016A2 ret
Contrast this with the code generated with #pragma optimize( "", off ):
163: void CAboutDlg::OnButton1()
164: {
004016A0 push ebp
004016A1 mov ebp,esp
004016A3 push 0FFh
004016A5 push offset $L77634 (00402180)
004016AA mov eax,fs:[00000000]
004016B0 push eax
004016B1 mov dword ptr fs:[0],esp
004016B8 push ecx
004016B9 push ecx
004016BA push ebx
004016BB push esi
004016BC push edi
004016BD mov dword ptr [ebp-10h],esp
004016C0 mov dword ptr [ebp-14h],ecx
165:
166:
167: try
168: {
004016C3 mov dword ptr [ebp-4],0
169: _asm int 5;
004016CA int 5
170: }
171: catch(...)
004016CC jmp $L77388 (004016e2)
172: {
173: AfxMessageBox("!");
004016CE push 0
004016D0 push 0
004016D2 push offset string "!" (00405070)
004016D7 call AfxMessageBox (00401cfc)
174: }
004016DC mov eax,offset $L77388 (004016e2)
004016E1 ret
175:
176:
177: }
004016E2 mov dword ptr [ebp-4],0FFFFFFFFh
004016E9 mov ecx,dword ptr [ebp-0Ch]
004016EC mov dword ptr fs:[0],ecx
004016F3 pop edi
004016F4 pop esi
004016F5 pop ebx
004016F6 mov esp,ebp
004016F8 pop ebp
004016F9 ret
Note the jmp $L77388 - this is where the exception framework takes over.
As for the nops, it may be that you have incremental linking enabled, and the compiler is just reserving space in the obj file so that the call can be recompiled in place. (Shouldn't have incremental on in release though).
So, is this a bug or a feature? I think I've been assimilated to the point where I'm too tired to argue - but it would be nice to have some better warnings - unreachable code ain't that bad, though - maybe should show at level 3.
|
|
|
|
|
Interesting stuff - the compiler seems to be changing the call format of the function, optimizing away the stack operations, which disables the exception framework.
I forgot the other side of the coin - since catch(...) is technically only for catching C++ exceptions/objects, the compiler has the right to get rid of the try/catch block here if it can see that no C++ exception can be thrown, which is true - the access violations in our codes are processor traps.
What's murky is how and why these traps _are_ translated and passed to our apps in such a way that a catch(...) handler will catch them - I think it was a decision made long ago and maintained for compatibility.
If this were written using windows Structured Exception Handling instead, the results might be different.
|
|
|
|
|
Thanks Tim!
Good to know about the pragma option, I hadn't seen that before.. but then again.. ouch, no optimization!
The thing I find most disturbing about it is how silent it is.. works great in debug.. then silently disappears in release. Very bad behavior IMO. The optimizer should issue a warning each and every time it throws away a block of functional code. Unused initializations are no big deal, 20 lines of code are quite another! I suppose I've just become one of those gluton for punishment error level 4 people.
I found that you can manually include the compile flag /EHa and this apparently will force the inclusion of all try/catch blocks regardless of whether any of the code will throw a c++ exception. Now that I've included the flag, the access violations are caught, but now I'm getting some other bizarre behavior I haven't been able to track down. If I can tie it to this, I'll be sure to follow up on this post.
Thanks again,
Matt
|
|
|
|
|
Ah.. well the /EH switch fills in some blanks - by using /EHa you are enabling asyncronous excepiton handlng, rather than the default of synchronous - thus telling the compiler that an exception can be thrown anytime, rather than just at a throw statement, as in /EHsc.
The /GX switch is said to be equivalent to /EHsc.
Be interesting to know what the strange behaviors are. Reading up on /EH helped me get little farther in understanding this stuff. The "Exception Handling: Default Synchronous Exception Model" topic in the MSDN is useful.
|
|
|
|
|
Well, the strange behavior was all my own.. wish I could say it wasn't! Pretty fun bug... created a recursing exception.
In my quest to handle the (...) case better, I explored the _set_se_translator function which allows you handle win32 exceptions, such as access violations, etc., by translating them into a c++ exceptions and throwing it. Exceedingly handy because you can then handle both c++ exceptions and Win32 SE's at once without using the (...) at all. By using this approach, you can identify everything about the SE, just as if you were using the __try/__catch approach. Very nice!
The only drawback to all this is that the handler table is created per thread, so, if you use multiple threads, you have to make sure you install the handler as the first step in every thread. This becomes especially fun when your code is called by someone else's multiple threads. (luckily, _set_se_translator returns the previous translator, so it can be saved and restored prior to return.) Small price to pay...
Matt
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
