Release builds usually optimize and this makes the debugger go wrong often.
If you want to see the values in Release it's probably better to use other means, writing them to a file or other external resource/tool.
I found on net that whenever you found something working on debug but not in release build then first of all Disable optimization under Project properties ->c/c++ Tab,Under Optimization category - >under option (optimization).
I choose to Disable from maximize speed in release build then its working.
But,I have doubt over this. What it should be the optimization in release build and If it is other than Disable option then how this problem can be solved.
Any Views ??
But,Anyway mine BitmapInfoheader problem is Solved.
Is there any way of doing it? I am trying to write some simple class for showing modeless dialog box and just cannot understand what is wrong with it. While it is pretty easy with DialogBoxParam - there seems to be no way with CreateDialog. My goal is to pass somehow a pointer to a class to call my dlgProc. The way i am doing it with modal dlgbox:
First, you probably have a main message loop somewhere that dispatches messages to every window (and dialog), not only to a specified window:
// global variable, it contains the handle of all dialogs
// your main loop somewhere near your main()
while (::GetMessage(&msg, NULL, 0, 0))
// copying the global array because it might be modified during iteration
// and we iterate over the copy...
bool was_dialog_message = false;
for (size_t i=0,e=dialogs.size(); i<e; ++i)
if (::IsWindow(dialogs[i]) && ::IsDialogMessage(dialogs[i], &msg))
was_dialog_message = true;
When you want a modeless dialog, you just create it with CreateDialog(), put its handle to g_Dialogs and thats it. You don't have to run a local message loop like with modal messageboxes, especially not with a specified single window handle (m_hWnd). A modeless dialog works almost like a normal window that you created with CreateWindowEx(), you just have to handle it a bit specially with IsDialogMessage(). In a modeless multi-windowed gui program its always enough one message loop - the main message loop pumps the messages for all modeless windows.
EDIT: warning: while you are iterating over the g_Dialogs vector, the contents of the vector might change because you dispatch messages to dialogs that can respond to those messages by creating/deleting dialogs! To avoid bugs caused by this you either use a custom container that can be modified during iteration or solve it somehow else. One good solution can be copying the vector before iteration and iterating on the copied vector, still some HWNDs might become invalid during iteration so before IsDialogMessage() it might be wise to call IsWindow() on the handles.
Hey, thanks for your reply. My problem was that i couldn't find a way to put the whole thing into nice C++ class of my own. But, problem was solved by using CreateDialogParam instead. So i can pass a pointer to the dialog class to a main message loop so i can call my own virtual methods inside children classes.
I though that your problem is the messagebox because your loop was inside the DoModeless() method. Anyway, your previous hooking is also fine, you just miss a few messages that come before the return of your CreateDialog() call and you have to handle uninitialized GWLP_USERDATA cases as well. Even if you initialize userdata from WM_INITDIALOG it might be better to handle uninitialized cases, who knows what the future brings?
EDIT: The trick is simple: the sendto address is in the header of the datagram you received, but your recvfrom returns just the payload from that and the address of the sender. You need a method to reach other fields of the received UDP packet header, one way is using raw sockets.
Programs under windows need administrator privilege must get user's permission when they start. And they can also run with administrator privilege by right click the EXE and select "Run as Administrator". But, before the EXE start, a message box will show up. It's really disgusting.
Now I want my application to run as the Administrator, and I don't want the popup message box when user click the EXE file.
Now I wonder whether AdjustTokenPrivileges can help me achieve this.
1. This program displays a running counter starting from 0 till infinity. The counter starts/resets by pressing enter and stops by pressing some other key. Use as many define directives and macros to achieve this task. The counter when played should be like a real counter (no separate line should be used for the
next counter increment). Hint: use clrscr() command inside the for loop.
Please try and do your own homework. If you get stuck on a particular part of the code then post a question here, but do not expect others to provide an entire solution without any effort on your part.
One of these days I'm going to think of a really clever signature.
I can predict the next posting... "I ran your code and it never reached infinity what could the problem be?"
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
I know how to code a catch block, I was just wondering whether you had posted in the correct forum. When you catch the exception it should contain sufficient information for you to discover what went wrong in your code.
One of these days I'm going to think of a really clever signature.
To my knowledge, MFC does not contain tools for managing task transactions. There is no common framework for managing undos, redos, etc...
The try / catch mechanism is a simplistic implementation of such a system, built into C++ that allows a program to gracefully unwind from an aborted task. the Afx classes that support exception handling, simply build upon this framework.
I have seen articles that discuss transaction processing for the windows file system and other kernel elements, coming up in future releases, but at this time, I don't know much about it.
You'll likely find that you'll need to roll your own Transactional Tasks manager for your application.
I have a dll developed in c#, which does some interactions with a web service, this all seems to be fine. I have made the dll visible to COM. I then register the dll using regasm passing it a /codebase /tlb argument. Again all this works fine. I now get a tlb file. From here i reference the tlb in my VC6 project like so:
// Import the type library.
#import "C:\\epos\\MyInterface.tlb" raw_interfaces_only
Once i compile the VC++ project i get a tlh file generated, which has the following contents (edited there is much more in this file just showing what is needed here):
I create COM earlier in the program so i have not included it in the code below.
Then i Create an instance of the c# class, to call the methods i need. Now this all works fine and i can call these methods and they work correctly.
Code in my Main.c file
IMyLinkPtr iPtrMyLink; //Global Variable
IChVRspPtr iPtrCheckVRsp; //Create the Interface to The CheckVoucher Response
short blnRetVal = 0; //Set to False Initially, return value from dll
IChVReqPtr iPtrCheckV(__uuidof(CChVReq)); //Create the Interface to The Method1 Class. This is another class in the dll
HRESULT hrRetval= E_FAIL;
hrRetval = iPtrMyLink.CreateInstance(__uuidof(CMyLink)); //This is the main class in the dll, a wrapper to call methods from.
// Pass to the method the request class, a reference to the response class and a reference to the return value.
iPtrMyLink->CallMethod1(iPtrCheckV, &iPtrCheckVRsp, &blnRetVal);
The problem i am having is that my program crashes after some time where the memory has grown to 32mb, which to me is quite low. The crash occurs on a CreateInstance line, not necessarily the one above but some other method i have to another .net dll. My main question is about memory, before calling this line:
The memory in the VC6 app is 12mb, once this line is called the memory jumps to 24mb. Is this down to loading the .net Framework and if i have another dll that does the same the memory will jump to 32mb and will crash shortly after when attempting to create an instance again. I am releasing the objects so im not sure what is going on here.
OK, this is a bit of a long shot, but any help would be appreciated...
I have a CWnd that contains a CHeaderCtrl and CTreeCtrl within a CDialog within a CScrollView within a CSplitterWnd within a CControlBar.
All works very well except the CWnd border (ClientEdge) is not redrawn (just seems to leave whatever was underneath) when splitter bar is moved, and CWnd is resized and invalidated. However, the edges ARE redrawn properly when the whole app is resized which also resizes panes in CSplitterWnd and subsequently CWnd in excatly same way as above. In other words, both scenarios call CSplitterWnd::RecalcLayout() which trickles down and drives all resizing of child view/dialog/window/tree control. The only difference I can really see is that one was generated by resizing whole app, while other was generated by StopTracking() of the CSplitterWnd. All other controls (buttons, group boxes, etc. resize and redraw fine).
A lot of web crawling suggests perhaps that it's something to do with being on a CControlBar which may result in some notify commands not getting to all children? But
I've tried trapping the paint messages, but am a bit confused as OnPaint seems to be being called...I'm now assuming that the window border isn't actually drawn by OnPaint? If it's not, where is it drawn and by whom?
Just playing around with painting in OnEraseBkgnd, I've noticed something very strange...if I get client rect and paint the background red, in the case where it's not repainting correctly, only an area at either end of the scroll bars to the right of the tree control are being painted red, where as in the case where it is working, the whole control is being painted red - the client rects are always same size.
Invalidating the CWnd doesn't fix the problem. Calling InvalidateRect(NULL) invalidates the whole screen which does fix the repainting, but is not a viable solution as there are graphs on the other bits of the screen that can take several seconds to redraw and shouldn't be redrawn any time the splitter bars are moved.
Anyone ever seen anything like this? I'm extremely confused and any pointers as to things to try would be much appreciated.
BTW - dialog in view in splitter wnd in ccontrol bar is part of a function panel down one side of the app.
"He is no fool who gives what he cannot keep to gain that which he cannot lose.
OK, while I've no idea why this happens, I've found a solution.
I've read up that OnNcPaint handles the borders (NC being Non-Client area). And it's this WM_NCPAINT message that never arrives in the situation where the border isn't painted. While I've no idea why this message isn't sent, sending a WM_NCPAINT message to the control after it's been resized ensures the frame is always repainted. Success!
"He is no fool who gives what he cannot keep to gain that which he cannot lose."