|
Make sure both the DLL and the EXE projects are using the same
CRT library.
Project properties/C++/Code Generation/Runtime Library
If you'll be passing allocations back and forth across the DLL/EXE
boundary, they both need to use the DLL version of the CRT.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Yes,there is one project using MFC in a static library and the other using MFC in shared DLLL.
I change their setting as the same,every thing works well now.Thank you.
Best wishes.
|
|
|
|
|
kcynic wrote: Best wishes
To you too! Happy Holidays!
Cheers ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
errors occur now!
The same library,I create a new user project(console,MFC surported).No matter I change their setting as Use MFC in a static library or Use MFC in a shared DLL,the user program will crash at the same position: delete
But the older user project(MFC dialog based) will work well no matter its MFC using setting is the same like the library or not.
How should I fix the error,now?Thank you
|
|
|
|
|
The problem here is that your EXE and the DLL are using different heaps: you are trying to free memory in one heap that was allocated in another.
There are two common ways around this problem:
1. Add a “DLL_free” exported function to the DLL which you use in the client to free any memory allocated by the DLL. It simply calls “free” but because the code which does this is in the DLL and not the client the correct heap is used.
2. Build the EXE and the DLL using a DLL version of the CRT.
Option 1 is more flexible and professional.
Steve
|
|
|
|
|
Thanks for your help.But I have some questions about the two options.
1.I believe the option 1 will work,but I want to know,if I should free a lot of heap blocks with different types,I have to define some DLL_free overides?
2.To option 2,I am sorry that,I do not know how to do it.In another word,how should I set this step by step?
|
|
|
|
|
I also find that their would be some problems about option 1.
Because if I fixed the delete crash,the following code like:
//in the caller
std::string str_temp = get_a_string(...);
...//do something
str_temp = get_another_string(...);//the same run-time error occur again here
...//do something
//in the library
std::string get_a_string(...)
{
std::string str;
...
str = ...;
return str;
}
function get_another_string return a string,too.
If export a DLL_free can fix the error,how about such error?
|
|
|
|
|
I recently transfered settings from my laptop to my new desktop. Doing so the laptop doesn't have a "Number Lock" key; so it eliminated the one on my new desktop. Does anyone know I can change the desktop back. I have no idea what to change.
|
|
|
|
|
|
You was correct - except it was under HKEY_USERS\Control Panel\Keyboard
A C++ programming language novice, but striving to learn
|
|
|
|
|
I work in an office with 8 developers and we all work on different parts of the same application. We all use DevStudio 2005 and work in primarily native C++. Recently when modifying dialogs some of the developer's systems modify the .rc file in such a way as to prevent more than 80 characters per line. Whereas developer's DevStudios allow the .rc files to have more than 80 characters per line. When we go to integrate our changes a 30 line difference ends up being lost in 1000's of lines of reformated data.
I have searched far and wide to find how to fix this very irritating problem. We have checked the MSN website, help, and other sites to no avail. We have also compared the registry setting for DevStudio under the HKEY_CURRENT_USER to see it there was any common difference. We all have service pack 1 installed. Any help or suggestions would be greatly appreciated, thanks.
|
|
|
|
|
I think my karma wants me to go home instead of staying at work today.
I'm using Dundas Grid compiled into a static lib that I want to link into a simple wizard dialog based application.
In the dialog header I have :
#pragma once
#include "Dundas_Grid/Include/UGCtrl.h"
...
class CtestGridDlg : public CDialog
{
public:
CtestGridDlg(CWnd* pParent = NULL);
protected:
CUGCtrl m_Grid;
};
and when the dialog class gets created, it all barfs up.
BOOL CtestGridApp::InitInstance()
{
CtestGridDlg dlg; m_pMainWnd = &dlg;
When CtestGridDlg is constructed, it will construct the CUGCtrl class and in that constructor something happens that completly messes up the memory.
In my project, I have 1 library (Dundas grid) and my wizard based dialog application, nothing else.
I have checked that both library and main application have "MFC in Shared DLL" , not using ATL, using multi-byte character sets, are build using the same calling conventions ( __cdecl (/Gd)) , the same runtime library ( Multi-threaded Debug DLL (/MDd) ), There are no additional macros or #define.
Now, I'm at a loss at what I have to look for in my project; The same sources work in our main source trunk, the settings are the same.
Any ideas before I start thinking throwing my computer across the room ?
Thanks and merry whatever.
|
|
|
|
|
I am sorry to ask so many queries, but:-
Thanks to previous help, I have got my graphics program adapted from Borland C++ 4.5 to Visual C++ 2008. When it is to read a JPG file, I have got as far as reading the file into a GDI+ 'class Image'. But please, how can I:-
Extract from a GDI+ `class Image' the contained image information data as described by a Windows BITMAPINFO and BITMAP?
Given a set of image information data in a Windows BITMAPINFO and BITMAP, create a GDI+ `class Image' using that data or a copy of it?
I have searched around in http://msdn2.microsoft.com/en-us/library/---- and not found what I was looking for.
|
|
|
|
|
One way to obtain a GDI bitmap from a GDI+ Bitmap is to use
Bitmap::GetHBITMAP() to get a copy as a GDI HBITMAP, something like:
Bitmap MyBitmap(L"C:\\some.jpg");
Color clr(0x00,0x00,0x00);
HBITMAP hbm;
MyBitmap.GetHBITMAP(clr, &hbm);
You can also build a DIBSection and extract the pixel data yourself,
something like:
Bitmap MyBitmap(L"C:\\some.jpg");
WORD BitsPerPixel = 24;
int BytesPerRow = (((MyBitmap.GetWidth() * (long)BitsPerPixel + 31L) &(~31L)) / 8L);
int PixelDataSize = MyBitmap.GetHeight() * BytesPerRow;
BITMAPINFO BitmapInfo;
BITMAPINFOHEADER *pBMIH = &BitmapInfo.bmiHeader;
pBMIH->biSize = sizeof(BITMAPINFOHEADER);
pBMIH->biWidth = MyBitmap.GetWidth();
pBMIH->biHeight = MyBitmap.GetHeight();
pBMIH->biPlanes = 1;
pBMIH->biBitCount = BitsPerPixel;
pBMIH->biCompression = BI_RGB;
pBMIH->biSizeImage = PixelDataSize;
pBMIH->biXPelsPerMeter = 0;
pBMIH->biYPelsPerMeter = 0;
pBMIH->biClrUsed = 0;
pBMIH->biClrImportant = 0;
BYTE *pPixelDataBytes = 0;
HBITMAP hBitmap = CreateDIBSection(NULL, &BitmapInfo, DIB_RGB_COLORS, (void **)&pPixelDataBytes , NULL, 0);
BitmapData bmData;
Rect bmRect(0, 0, MyBitmap.GetWidth(), MyBitmap.GetHeight());
MyBitmap.LockBits(&bmRect, ImageLockModeRead, PixelFormat24bppRGB, &bmData);
BYTE *pCurrentSourceByte = (BYTE *)bmData.Scan0;
BYTE *pCurrentDestinationByte = pPixelDataBytes + ((MyBitmap.GetHeight() - 1) * BytesPerRow);
int DestinationStride = -BytesPerRow;
for (UINT CurY = 0; CurY < MyBitmap.GetHeight(); ++CurY)
{
memcpy(pCurrentDestinationByte, pCurrentSourceByte, BytesPerRow);
pCurrentSourceByte += bmData.Stride;
pCurrentDestinationByte += DestinationStride;
}
MyBitmap.UnlockBits(&bmData);
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Thanks; but after the line
Bitmap MyBitmap(L"C:\\some.jpg");
please how can I check if the read failed?
|
|
|
|
|
Anthony Appleyard wrote: how can I check if the read failed?
using namespace Gdiplus;
...
Bitmap MyBitmap(L"C:\\some.jpg");
if (Ok != MyBitmap.GetLastStatus())
{
}
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks for your help here.
However, the function as it now stands (without text which I commented out to track the bug down)) is:
short jpgread (image&I,char*filename){
int i,n=strlen(filename),CurY; WCHAR fn[600];
for(i=0;i<=n;i++) fn[i]=filename[i];
using namespace Gdiplus;
GdiplusStartupInput gdiplusStartupInput;
ULONG_PTR gdiplusToken;
GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL);
Bitmap MyBitmap(fn);
GdiplusShutdown(gdiplusToken);
return 1;}
which causes
Unhandled exception at 0x73826a6a in ppp_vc.exe: 0xC0000005: Access violation reading location 0x011b227c.
in the function
inline Image::~Image() { DllExports::GdipDisposeImage(nativeImage);}
in GdiPlusBitmap.h
The stack frame dropdown says that this was called by
Gdiplus:Image::~Image() (line 92), which was called by
Gdiplus:Bitmap::Bitmap() + 0x2b bytes, which was called by
the jpgread() shown here.
I was compiling in the mode "align struct elements on multiples of 1".
-------------------
If I remove the line
Bitmap MyBitmap(fn);
the function runs through without error-exiting (but does nothing useful).
I inserted statements giving values to the elements of the struct gdiplusStartupInput, but it still error-exited in Image::~Image().
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please also, how can I put an existing HBITMAPINFO and HBIPMAP into a `class Image' or `class Bitmap' and then output it to a JPG file?
<div class="ForumMod">modified on Saturday, December 22, 2007 5:58:56 AM</div>
|
|
|
|
|
Anthony Appleyard wrote: for(i=0;i<=n;i++) fn[i]=filename[i];
I'm not sure how you got that to compile, but you
need to actually convert the char string to a
WCHAR string before passing it to the constructor.
One way is with the ATL string conversion macros....
#include <AtlConv.h>
...
using namespace Gdiplus;
...
short jpgread (image&I, char*filename)
{
GdiplusStartupInput gdiplusStartupInput;
ULONG_PTR gdiplusToken;
GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL);
CA2W wcharfilename(filename);
Bitmap MyBitmap(wcharfilename);
GdiplusShutdown(gdiplusToken);
return 1;
}
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
GdiplusShutdown must be called out of scope of the Bitmap object.
The Unhandled exception arise because the GdiplusShutdown function is called
before the Bitmap object is destructed.So define Bitmap object within { }.
<br />
short jpgread (image&I, char*filename)<br />
{<br />
<br />
GdiplusStartupInput gdiplusStartupInput;<br />
ULONG_PTR gdiplusToken;<br />
GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL);<br />
{<br />
CA2W wcharfilename(filename);<br />
<br />
Bitmap MyBitmap(wcharfilename);<br />
}
GdiplusShutdown(gdiplusToken);<br />
return 1;<br />
}<br />
<br />
|
|
|
|
|
Graphis g;
Rect rt;
...
g.TransformPoints(CoordinateSpaceWorld,CoordinateSpacePage,(Point*)&rt,2);
BTW the way, for example, there are two ways to do invalidate:
a. Invalide(FALSE)
b. Calculate a rect to invalidate(calc bound box including a bound box of a rotated rect, and do Rect::Union about 3 times, and with some if...else...),and do InvalidateRect
In OnDraw, only copy a memory Grahpics to the screen.
Which is more efficient?
|
|
|
|
|
followait wrote: Why does the trick fail, one Rect to two Points
Maybe because a Gdiplus::Rect is a point and a size, not two points.
followait wrote: Which is more efficient?
I'm not sure what you're asking. The less pixels rendered to the screen,
the more efficient drawing will be. Unless your calculated rect is always
close to the size of the entire window, using method b should always be more
efficient.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
about the invaliate question
Because it is a little complex to calculated the rectangle, which needs to be redrawn, also the code became less clear. Here is a sample code:
Rect rt;
if (m_pCtrlBoxSizing) {
m_pCtrlBoxSizing->GetBoundRect(&rt);
} else if (m_pCtrlBoxRotating) {
m_pCtrlBoxRotating->GetBoundRect(&rt);
} else if (m_pCtrlBoxMoving) {
m_pCtrlBoxMoving->GetBoundRect(&rt);
}
Rect::Union(rt,rt,m_HotRt);
InvalidateRect(&CRect(rt.GetLeft(),
rt.GetTop(),
rt.GetRight(),
rt.GetBottom()),FALSE);
or with a simple line
Invalidate(FALSE);
In OnDraw, there is only a bitblt
|
|
|
|
|
Only you can decide what's more important - clear code or
performance. +-10 simple lines of code isn't all that unclear
IMO 
Of course, at some point, calculating an update region could
take longer than drawing all the pixels. That's application
specific - you'll have to determine that.
I personally have always got better performance by using update
rects/regions over full redraws. That's in my applications.
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Any way to make it more clear?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
