|
Try a MoveWindow() (you can even resize your dialog with this one) like this :
MoveWindow(x,y,DialogSizex,DialogSizey,TRUE);
where x and y are your coordinates, DialogSizex the width and DialogSizey the height of your window.
RaGe
|
|
|
|
|
hi friend
i always prefer SetWindowHandle()API..BCzthat i sthe simple and traditional way to locate the window
the way must use
SetWindowPos(
HWND hWnd, // handle to window
HWND hWndInsertAfter, // placement-order handle
int X, // horizontal position
int Y, // vertical position
int cx, // width
int cy, // height
UINT uFlags // window-positioning options
)
i think ur doubt is about the second parameter hWndInsertAfter here just put HWND_TOPMOST which Places the window above all non-topmost windows
The TRUE CP -ian
|
|
|
|
|
In your WM_INITDIALOG handler, call SetWindowPos() and pass the x,y values you want the dialog to appear in. (Note that in MFC, you cannot use (0,0) since that is the default location and MFC will call CenterWindow() for you. Using any other position overrides this behavior.)
--Mike--
Just released - RightClick-Encrypt - Adds fast & easy file encryption to Explorer
Like the Google toolbar? Then check out UltraBar, with more features & customizable search engines!
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
|
|
|
|
|
just try the CRect class members .. it works ..
|
|
|
|
|
Anybody here done any work with Exchange 2000 in C++. Can you recommend any good books for building solutions with Exchange?
Michael 
|
|
|
|
|
The VC debugger is reporting memory leaks but not giving me source file name or line numbers as outlined in the following MSDN article for DumpAllObjects:
<url>http://msdn.microsoft.com/library/en-us/vccore98/HTML/_core_dumping_all_objects.asp
As you notice the example displays filename and line number where the leak occured. I have been trying all kinds of things but cannot get it to display this way (in debug window, file, or console window). I only get:
Dumping objects ->
{372970} normal block at 0x0242AEB8, 8 bytes long.
Data: < xL > 08 78 4C 10 01 00 00 00
and more like it. I have been using CMemoryState objects and _CrtSetReportMode, _CrtSetReportFile, etc. I have put all of that code in the main() function hoping it will catch all errors in all other modules.
Does anyone know how to do this and/or have an example????? TIA.
|
|
|
|
|
see that first number? that's the allocation number.
put this at the very beginning of your app:
_crtBreakAlloc = 372970;
you'll get an assertion when that allocation happens. back up the call stack and there you go... the only trick is to make sure you run the app exactly the same way - since you're breaking on the Nth memory allocation. if you change the allocation order even by one, you'll be lost.
-c
Cheap oil. It's worth it!
|
|
|
|
|
OMG, I never knew about that!!!
(makes notes)
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
fun geek trivia
-c
Cheap oil. It's worth it!
|
|
|
|
|
I'll second Tim , here . Neither do I 
This is sometimes nice to use instead of the break at memory address
Adding this to my favourites ... this could cause some delay due TCL speed limitations ... done !
Thanks Man !
Cheers,
Joao Vaz
A person who is nice to you, but rude to the waiter, is not a nice person - Natalie Portman (Padme/Amidala of Star Wars)
|
|
|
|
|
Chris Losinger wrote:
put this at the very beginning of your app:
_crtBreakAlloc = 372970;
you'll get an assertion when that allocation happens.
Cool trick.
Where did you learn this useful tidbit?
--
Dana Holt
Xenos Software
|
|
|
|
|
i think it's in the MSDN somewhere.
-c
Cheap oil. It's worth it!
|
|
|
|
|
I've done that before...takes me to DBGHEAP.C and tons of assembly code. Why won't it do as the example says and identify source code filename and line number?
|
|
|
|
|
it's not supposed to.
what happens when you look back in the call stack??
-c
Cheap oil. It's worth it!
|
|
|
|
|
I'm not sure what you mean. From the breakpoint caused by using the allocation number, I just hit F10 and single stepped through hundreds of lines of assembly code (and some of the stuff in that debug.c file) that happened to be in the crt debug stuff . I've got 40 converted files from BC to VC and I'm writing test code. I'm currently only testing a small portion of it and I don't want to have to trace every single call back if I have to do it that way when I test all of the code.
|
|
|
|
|
Debug Menu, Step Out
or View Menu, / Debug Windows / Call Stack. double click on the first file name that looks like it could be in your app.
-c
Cheap oil. It's worth it!
|
|
|
|
|
I tried it. Thank you. Seems like my leaks are strange though. Most are occuring in the iostream or STL library.
Examples. I do something like call push_back() on a STL linked list of longs or I'm doing a file open via open(filename, modePassed).
Or,I make a call to strstream like:
streamBuff << " " << setfill('0') << setw(3) << (GetPort() + 1) << setfill(' ');
Doesn't make sense.
|
|
|
|
|
it could be that the allocation number is changing from run to run. if you run your app exactly the same way a few times in a row, do the reported leaks always have the same allocation number? if not, then unfortunately, this technique won't work bceause the order of allocations is changing.
but, i'm with Tim on the fact that you've probably spent enough time on this to pay for a copy of BoundsChecker or Purify. in fact, you can download and install a trial version of Purify (14 days) and it will tell you instantly where your leaks are. www.rational.com. also, this might help you (it does memory leak detection) and comes with a 30 day trial. either way, tools like these are worth the price.
-c
Cheap oil. It's worth it!
|
|
|
|
|
Yes. I am running the App the same way everytime with no changes.
Sounds like a good investment for Boundchecker or Purify....I'll look into them. I was hoping that the integrated memory leak detection in VC++ would be good enought but apparently not.
Thanks
|
|
|
|
|
here's a better way:
add this code to your app:
#ifdef _DEBUG
void* operator new(size_t nSize, const char * lpszFileName, int nLine)
{
return ::operator new(nSize, 1, lpszFileName, nLine);
}
#define DEBUG_NEW new(THIS_FILE, __LINE__)
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
then call _CrtDumpMemoryLeaks(); at the end.
this simply adds the line number and file to the memory allocation. (only works with "new", of course)
Cheap oil. It's worth it!
|
|
|
|
|
Great. Thanks. I'll give that a try. I'm only using new anyways.
|
|
|
|
|
oh, and here's how you do it for malloc, too:
#define MALLOC_DBG(x) _malloc_dbg(x, 1, THIS_FILE, __LINE__);
#define malloc(x) MALLOC_DBG(x)
i smell an article...
-c
Cheap oil. It's worth it!
|
|
|
|
|
Chris Losinger wrote:
i smell an article...
Looking forward to it!!!
This is very interesting stuff that I did not know. An article would be great!
---
CPUA 0x5041
Sonork 100.11743 Chicken Little
Orgasms are universal!!  -- Mike Mullikin in The Lounge 21:27 15 May '02
|
|
|
|
|
Another way to do this is to add the following define to your preprocessor settings:
_CRTDBG_MAP_ALLOC
By adding this define, all new and malloc calls are converted to the debug version of the calls.
Best regards,
John
|
|
|
|
|
that doesn't work with "new", tho. the file/line reported is in crtdbg.h, where the new version of "new" is defined, not where you actually called it.
-c
Cheap oil. It's worth it!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
