|
Where does it crash? Do you have kernel symbols set up? What function?
|
|
|
|
|
It crashes on this line: locale mylocale("");
What are "kernel symbols"?
|
|
|
|
|
You're not passing a valid locale name to the constructor.
Here is an excerpt from the documentation -
If a locale name _Locname is a null pointer or otherwise invalid, the function throws runtime_error.
|
|
|
|
|
I don't think so.
Every single example on the internet I've seen has locale("")
|
|
|
|
|
I'm using Image::GetThumbnailImage() to load some JPG files into an image list that is then attached to a list control. Most of the pictures display, but a few don't. Those that display, have widths that equal or exceed their heights (landscape). Those that don't display, have heights that exceed their widths (portrait), and GetThumbnailImage() does not return an error value.
I'm scaling the images down and maintaining the aspect ratio using the following code:
int nMaxPixels = 16;
int nOriginalWidth = bitmap.GetWidth();
int nOriginalHeight = bitmap.GetHeight();
double dFactor;
if (nOriginalWidth > nOriginalHeight)
dFactor = (double) nMaxPixels / nOriginalWidth;
else
dFactor = (double) nMaxPixels / nOriginalHeight;
int newWidth = nOriginalWidth * dFactor;
int newHeight = nOriginalHeight * dFactor;
I then add to the image list and the list control using:
Bitmap *pThumbnail = (Bitmap *) bitmap.GetThumbnailImage(newWidth, newHeight);
HBITMAP hBMP;
pThumbnail->GetHBITMAP(Color(255, 255, 255), &hBMP);
CBitmap mfcBitmap;
mfcBitmap.Attach(hBMP);
m_imageList.Create(16, 16, ILC_COLOR32, 5, 1);
int nImage = m_imageList.Add(&mfcBitmap, RGB(255, 255, 255));
if (nImage >= 0)
m_listCtrl.InsertItem(nImage, fileFind.GetFileTitle(), nImage);
mfcBitmap.Detach();
delete pThumbnail;
Another oddity worth mentioning is that sometimes CImageList::Add() will return an existing item number. I'm not sure yet if this is related or not.
If I make the following change when calling GetThumbnailImage(), all of the pictures display although the portrait ones are stretched:
Bitmap *pThumbnail = (Bitmap *) bitmap.GetThumbnailImage(max(16, newWidth), newHeight);
Thanks.
- DC
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
At the risk of telling you something you already know, here are a few CP articles that discuss this:
Thumbnails viewer and image processing using GDI+ and MFC[^]
Thumbnails Viewer using ListCtrl[^]
MSDN has the warning "The GetThumbnailImage method works well when the requested thumbnail image has a size of about 120 x 120 pixels. If you request a large thumbnail image (for example, 300 x 300) from an Image that has an embedded thumbnail, there could be a noticeable loss of quality in the thumbnail image. It might be better to scale the main image (instead of scaling the embedded thumbnail)."
|
|
|
|
|
From MSDN[^]:
An "image list" is a collection of same-sized images, each of which can be referred to by its zero-based index. Image lists are used to efficiently manage large sets of icons or bitmaps. All images in an image list are contained in a single, wide bitmap in screen device format.
That really puts some constraints on what you can stuff in there.
You will have to add space to your thumbnail, to make it conform to whatever size you give upon construction of the image list. Wider and higher might work, since I believe those images are just clipped to fit the size.
|
|
|
|
|
Niklas Lindquist wrote: An "image list" is a collection of same-sized images,
'Tis true they are the same size after they are added to the image list, but I don't think they need to be beforehand. For example, I've got one picture that is 3264x2448 and another that is 2147x1390, and they both display fine.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
You can add images that are wider than your set up 16 pixels, but not narrower. A wider image will be clipped to fit the width. A narrower image will be rejected. Check CImageList::GetImageCount() after you have added an image to see if it was accepted. (Don't trust the return value of CImageList::Add() for this.)
You will have to add space to your thumbnail 
|
|
|
|
|
Niklas Lindquist wrote: You will have to add space to your thumbnail 
Any reading suggestions for this?
[edit]
I found what I was looking for with Graphics::FromImage() and Graphics::DrawImage(). Thanks!
[/edit]
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
modified on Wednesday, March 2, 2011 2:17 PM
|
|
|
|
|
I was going to suggest this:
CImage img;
img.Load("narrow.bmp");
COLORREF clrFill = RGB(255, 255, 255);
int leftEdge = (16 / 2) - img.GetWidth() / 2;
CDC *pDC = GetDC();
CDC dc;
dc.CreateCompatibleDC(pDC);
ReleaseDC(pDC);
CBitmap bm;
bm.CreateBitmap(16, 16, 1, 32, NULL);
BITMAP bitmap;
bm.GetBitmap(&bitmap);
CBitmap *pOldBm = dc.SelectObject(&bm);
dc.FillSolidRect(0, 0, 16, 16, clrFill);
img.BitBlt(dc.m_hDC, leftEdge, 0, SRCCOPY);
img.Draw(dc.m_hDC, leftEdge, 0);
dc.SelectObject(pOldBm);
imagelist.Add(&bm, clrFill);
bus I suppose gdi+ has more to offer.
|
|
|
|
|
Hi all,
I've a 32 bit DLL that needs to register 2 other DLLs. One of these DLLs are 64 bit, and another is 32 bit. I know that I can simply load the DLL and call DllRegisterServer for the 32 bit DLL.
However, I am not sure how can I proceed with registering the 64 bit DLL. There are several ways like:
1. RegSvr32.exe [DLL name here]
2. RunDll32.exe [Dll name here] [DllRegisterServer]
and so on...
However, windows is forcing file system virtualisation upon my process since it's 32 bit, and the calls to the above executables are invoking the corresponding 32 bit versions (from within C:\Windows\SysWOW64), even if I hardcode the path to C:\Windows\System32 (where the 64 bit versions reside). And because the 32 bit versions of those applications are called, they fail to load my 64 bit DLL.
Is there a way to temporarily disable WOW from within my code, so that I can actually execute the 64 bit version of those applications? Or is there any other workaround?
Note: I do not want to build a 64 bit version of this particular DLL (the one which wants to do all the registration).
Any help will be appreciated. Thanks!
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
|
I don't have VS installed on this machine now to test it. However, I'm fairly sure that this should be a straight forward way of resolving my problem by bypassing the WOW mode!
Many thanks!
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
I also have realised that I could call SHGetFolderPath() by passing in the appropriate CSIDL (in my case, it is 32 bit process running in WOW mode on 64 bit windows):
CSIDL_SYSTEM to retrieve the 64 bit system32 folder
CSIDL_SYSTEMX86 to retrieve the WOW mode system32 folder Note that this applies only for a 64 bit operating system. If the OS is 32 bit, then both the above calls will return %windir%\System32, because there's no WOW mode.
More information can be found in this MSDN page: http://msdn.microsoft.com/en-us/library/dd378457(v=VS.85).aspx[^]
With this way, I was able to execute both versions of regsvr32 without having to by pass the WOW file system redirection!
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
How can I check if a string is base64 encoded string? 
|
|
|
|
|
Manually check whether the string contains only the characters (A-Z, a-z, , 0-9, + and /) that can be the output of Base64 encoding. Such a string can be successfully decoded. 
|
|
|
|
|
|
1. Check if the length is an exact multiple of 4.
2. Try to decode it and catch any error.
|
|
|
|
|
|
Can't understand why someone downvoted this.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Is there already a function in Windows that can extract just the volume name from a fully qualified path?
For example:
C:\Path1\path2
should return
"C:\"
and
\\MyServer\MyShare\text.txt
should return
"\\MyServer\MyShare\"
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I found it:
GetVolumePathName()
Retrieves the volume mount point where the specified path is mounted.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
