|
Hi,
you must use this code :
AcDbDatabase* pDb=NULL;
pDb=acdbHostApplicationServices ()->workingDatabase ();
pDb->saveAs("d:\\pokus.dwg");
Libor Matejka
|
|
|
|
|
Hi,
In my OnMouseMove(...) I'm loading a bitmap like so:
<ccode>
CSize sizeOfBmp = m_dibMask.GetSize();
CBitmap *pOldBm = pDibMask->MakeBitmap(&m_dib, &dc, sizeOfBmp);
//This is to fix Dundas bug
delete dc.SelectObject(pOldBm);
dc.SelectObject(pOldBm);
Since my masked image (I'm using a masked image to create "hotspots") get's loaded everytime the mouse moves in the view, I was wondering if it's possible to do the above code but somehow persist the dc so I can make a call to dc.GetPixel(...) without actually having to load it all over again. My masked image is about 800k so I'm thinking that if I can persist the dc I can gain some performance.
Also, in my UI, the user can change the image/mask pair by selecting a different image, will this cause any problem?
Thanks for any help you can provide,
Craig
|
|
|
|
|
You could make it static or make it a member variable and set it up in your initialisation.
I just reread your post - I'd make it a member variable and then delete/recreate when the user changes what it is.
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
Thanks for the info Christian. Just so I'm clear on what you mean.
1. Create member variable in my .h file
CDC dc;
2. In my loadFile function (when the user selects a new imgage.)
if(dc != NULL)
delete dc;
dc.CreateCompatibleDC(NULL);
CSize sizeOfBmp = m_dibMask.GetSize();
CBitmap *pOldBmp = m_dibMask.MakeBitmap(&m_dibMask, &dc, sizeOfBmp);
//Fix Dundas bug
delete dc.SelectObject(pOldBm);
3. In my destructor
if(dc != NULL)
delete dc;
I'm kind of questioning the deletion of the dc, how do I do that correctly without creating memory leaks?
Thanks again for all your help,
Craig
|
|
|
|
|
No, this is dodgy - it won't compile. You are treating the variable DC as a pointer when you check for NULL and call delete, but it isn't one.
You can get the same effect without using a pointer by using dc.DeleteDC(); which will get rid of anything that was there before, but not crash if it was empty.
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
Yes, that works correctly and doesn't even crash  . The only thing I question about this whole situation is, the call to
CBitmap *pOldBm = m_dibMask.MakeBitmap(...)
is basically making a call to SelectObject which returns the old object. According to the documentation you should always call SelectObject using the originally selected object, in this case pOldBm. Will I run into any memory leaks by not selecting the old pOldBm back into SelectObject()?
Thanks again for all your help, it's actually working  ,
Craig
|
|
|
|
|
There's no point catching it if you don't put it back in ;0)
Usually this is a major disaster, but if you create the DC afresh before selecting the bitmap, the one coming out is 1x1x1, in other words, it's not really important. You could store the bitmap *, and check it for NULL before deleting the DC to know if you need to select it back in, but I doubt it's necessary...
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
I see now, so I will have to worry about this when for instance I open up another image using the same dc right?
Currently, I have the following code in my LoadImage(...) method
if(m_dc != NULL)
dc.deleteDC();
m_dc.CreateCompatibleDC(NULL);
CBitmap *pOldBm = m_dibMask.MakeBitmap(...);
So, for the dc.deleteDC() do I need to worry about saving the old bitmap? Or, does deleting the dc pretty much mean I'm starting with a clean one again without worrying about selecting the old bitmap back in?
Thanks again for all of your great help to get me to understand how all this dc stuff works,
Craig
|
|
|
|
|
Yes, you've got it. Don't bother catching it, unless you want to use a member variable, and select it back before calling DeleteDC(); It's probably better that you do, but I doubt you'll notice any difference if you don't.
Glad to help
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
I wrote an STL version of my CQStringParser class, and in order for it to compile cleanly at warning level 4, I had to do the following:
#pragma warning (push, 3)
#pragma warning (disable : 4786)
#include <list>
#include <string>
#pragma warning (pop)
Why do I have to pragma around those includes? Is this just an example of Microsoft's inability to develope standard code?
Next question - When I run the app, Boundschecker reports memory and resource leaks in the very same files that generate the warnings. Why?
I guess I just don't get it - what does the STL bring to the table that MFC doesn't do as well or better?
|
|
|
|
|
about the warnings... they're just warnings. no big deal. i have the same pragmas everywhere and sometimes it takes 2 or more of them per file to get rid of all the warnings.
but what does STL bring ?
std::random_shuffle(fileArray.begin(), fileArray.end());
std::reverse(fileArray.begin(), fileArray.end());
std::sort(fileArray.begin(), fileArray.end());
yes, you can do those with CArray, if you write extra code, or with qsort (if you write extra code). but with STL, it's already there.
stack, queue (deque), set, etc. are all already implemented, no need to fake them with CArray or CList.
portability.
it's not MFC! there are many situations where MFC is not an option. STL is almost always an option.
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
I only get those warnings with STL stuff so I just have a generic "Warnings.h" file that I include when I use STL headers that disables that warning.
M$'s STL implementation isn't the best. There are memory leaks that are known and have been documented. You might want to drop in a better STL library such as stlport.org.
|
|
|
|
|
M$'s STL implementation isn't the best.
In fact, the STL included in VC6 was developed by PJ Plauger of Dinkumware.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I guess I just don't get it - what does the STL bring to the table that MFC doesn't do as well or better?
I'm only repeating myself and others, but I've already noted I am an STL zealot, so.....
I've actually recently read that the MFC containers were a stopgap as STL only recently became part of the standard. Having said that, you should certainly get stlport instead of using M$ crappy implimentation.
STL gives you a whole swag of cool functions you can plug in, a number of containers such as queue, vector, map ( which is a tree ), list, all of which can be plugged into the algorythms and work with each other ( so I can copy the contents of a tree into a vector in one line of code ). You can also write custom iterators for your own containers ( MSDN had an example that created an iterator for favourites from IE, meaning they could then be manipulated by the STL algorithms ).
I'd definately recommend this book:
The STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library
It's written by people who worked with Stepanov when he was writing it, and Stepanov himself provides the foreword. To date, everyone I have put onto this book has loved it and the STL.
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
One reason the warnings are generated is due to these templates producing names longer than 256 chars... gotta love templates.
|
|
|
|
|
You can always disable some specific warnings in your pre-compiled header file and never re-enable them. This could be the case for the warning about the length of identifiers.
Also you can uses #pragma include_alias (again from your pre-compiled header file) to include a wrapper file instead of the STL file and from your file, you do a pragma push and a pragma pop before and after including the original file (spelled differently so pragma include_alias won't causes a loop).
Personally I think that at level 4, many warnings are preferable that coding wiothout them. This is even the case for some warnings at level 3. For ex. I do think that a cast is worst that a warning about possible truncature.
However, I do thing that Microsoft should have added the pragma push and pop in the implementation they uses so that with correct code, we won't have any warning in STL files (in fact, warnings settings should not affect standard files when the warning do not depends on the client code).
Philippe Mori
|
|
|
|
|
newbie struggling to understand the difference..
the heap or free-store is unallocated, available memory?
the stack refers to the memory your application is using, constantly shifting as things go in and out of scope (i.e. like a 'stack' of blocks or something thing, you put new ones on top, you take one out at any point and the rest collapses to the new 'stack' of memory?)
Or not?
Many thanks.
|
|
|
|
|
I guess I'll try to take a stab at this, and people who know more than me (most of you) can build on it:
Imagine your computer's memory as a vertical list of memory addresses, ready to be used by whoever. Generally, the stack is just the name for a certain chunk of memory locations at the bottom of the memory, and the heap is everything else on top of it. So, certain actions allocate memory on the heap (the "new" operator) and certain actions use memory in the stack's section (arguments to functions, i think). But basically, it's just two different sections of memory, with the heap starting at the top and growing down, and the stack starting at the bottom and growing up, and programs know what parts they're allowed to use.
I hope this helps, and that I'm not too wrong, since I took a computer architecture course last semester and don't want my prof to kill me
Jake
|
|
|
|
|
Actually, on an intel it is the other way around.
i.e. The stack grows downwards (or backwards),
the heap grows upwards (or fowards) in memory.
The heap does not necessarily have to be below
the stack either - it is just a large block of
memory reserved by the heap manager
James.
|
|
|
|
|
Hi!
I'm writing a function in CMainFrame - and in that function I need to know if my program is minimized/maximized, how do I do that?
|
|
|
|
|
CMainFrame is derived ultimately from CWnd
So you can use CWnd::IsIconic() and IsZoomed.
|
|
|
|
|
Well .. I'm minimizing to the systray .. so I can't use IsZoomed and IsIconid ;(
Is there another way?
please guys, I'm desperate!
|
|
|
|
|
Therefore what i'd do is this:
Add member var to your dialog class:
BOOL m_bWindowState;
Handle OnSize in your dialog:
void CExperimentDlg::OnSize(UINT nType, int cx, int cy)
{
CDialog::OnSize(nType, cx, cy);
m_bWindowState=nType;
if (nType == SIZE_MINIMIZED) {
ShowWindow ( SW_HIDE );
}
}
Then, you can programmatically assess the window state by looking at m_bWindowState. Compare it with SIZE_* defines to see whats happening.
|
|
|
|
|
|
I'm having a problem getting rid of the "x" button (close) in my program. I only want to have the "-" button (minimize). The right place for these changes are in BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs), the cs.style .. right?
Well, I hope you've got some answers for me 
Lily
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
