C / C++ / MFC

Michael Dunn2-Jul-01 18:52

Michael Dunn

2-Jul-01 18:52

I use this:

typedef std::basic_string<TCHAR> _tstring

Don't forget that I/O streams have different versions too:

#ifdef _UNICODE
  #define _tcout wcout;
  #define _tcin wcin;
  #define _tcerr wcerr;
#else
  #define _tcout cout;
  #define _tcin cin;
  #define _tcerr cerr;
#endif

--Mike--
http://home.inreach.com/mdunn/
"Holding the away team at bay with a non-functioning phaser was an act of unmitigated gall. I admire gall."
-- Lt. Cmdr. Worf

Nick Blumhardt2-Jul-01 19:11

Nick Blumhardt

2-Jul-01 19:11

thanks Michael Smile | :)

think we need more stl warriors in this MFC-polluted world...

nb

2-Jul-01 21:30

One thing you need to be clear on - do you want to be able to create a single exe that works on both ASCII and UNICODE systems, or do you want to create a code base that can be compiled into an ASCII exe and a separate UNICODE exe ?

The entire 'TCHAR' concept that microsoft has developed is for creating a single set of source that can be compiled into both ASCII and UNICODE versions. If you are writing a program that will only be ASCII, or only UNICODE, or if you a writing a program that must be able to handle both, then the TCHAR style of coding is useless.

The TCHAR/typedef approach might seem like a good idea, but there are much more significant differences between ASCII and UNICODE code other than the size of the storage uhit (8 bit or 16 bit) - for example, upper/lower case conversion is completely different between ASCII and UNICODE, so a function like :

"void ToUpper(_tstring& input);"

is of limited value, since although it will compile into ASCII and UNICODE versions, it will probably only work correctly in one or the other!

In general, I have found that if Unicode is required, or likely to be needed, it's better just to write the entire program in std::wstring, and convert to/from ASCII(std::string) at the "edges".

3-Jul-01 5:02

It is always usefull to use TCHAR, this will help port the code in the future! You might not wan't unicode at the moment, but in the future who knows?

3-Jul-01 12:30

You have missed the point - TCHAR addresses the storage issue (8 bit versus 16 bit), but nothing else.

When you say something like : "You might not wan't unicode at the moment, but in the future who knows?", you are implying that the only thing that is different between a UNICODE string and an ASCII string is it's size. This is completely incorrect! A program that is written using TCHAR is NOT a UNICODE program - it is a program that uses 16 bits to store each ASCII character. If "in the future" you really do want a UNICODE program, then you will have to review and probably rewrite any and all code that actually examines the strings in any way (especially I/O code), to reflect to details of the UNICODE specification.

There are two main reasons to use UNICODE in a Windows program.

1. Efficiency. Since NT/2000/XP are all UNICODE systems internally, you avoid the 'thunking' layer of the 'A' versions of the API if you use the native 'W' versions (turned on by "#define _UNICODE"). In this case you get some sort of efficiency gain, but you re NOT writing a true UNICODE program - you are writing a UNICODE program that uses only the ASCII subset. Of course you can do this, but do not fool yourself into believeing you are writing a UNICODE program!

2. True UNICODE. In this case you are writing a program that needs to deal with Asian, Middle Eastern or European languages. UNICODE gives you the ability to store all of these, but you must work carefully to write code that works with strings - TCHAR is of no use at all for this!

I have found that if you are using UNICODE for point(1), then TCHAR has value - it allows you to write one code base, then compile it into different exe's - one ASCII, one UNICODE. The UNICODE version will have a slight performance boost.

However, if you are writing UNICODE for reason (2), then I have found TCHAR to be more trouble than it is worth - it constantly 'hides' the real type, and allows code to be written that will com;ile in different environments, but which does not correctly run in thise environments - in other words, it is very dangerous to write 'library' code using TCHAR, and then assume that it actually is UNICODE compliant.

[James Pullicino]3-Jul-01 5:18

[James Pullicino]

3-Jul-01 5:18

USES_CONVERSION;
A2W("I agree with you.");

(2b || !2b)

load image

Kathrin2-Jul-01 16:08

2-Jul-01 16:08

I try to create an image app based on Sam Teach Yourself Visual C++ in 21 Days chapter - 8 - Adding Flash--Incorporating Graphics, Drawing, and Bitmaps. The example shows that in order to load an image requires some kind of open file function, but I don’t want to use that function. I want to load my image that I’ve initialized. So I didn’t use some functions mentioned on the example, and it caused an error. The error is saying :
Debug Assertion failed. File afxwin1.inl. Line 418.
And the code is :

// ImageDlg.cpp : implementation file
void CImageDlg::OnBitmap()
{/*I did’t use this function to load the image
// Build a filter for use in the File Open dialog
static char BASED_CODE szFilter[] = "Bitmap Files (*.bmp)|*.bmp||";
// Create the File Open dialog
CFileDialog m_ldFile(TRUE, ".bmp", m_sBitmap,
OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, szFilter);

// Show the File Open dialog and capture the result
if (m_ldFile.DoModal() == IDOK)
{
// Get the filename selected
m_sBitmap = m_ldFile.GetPathName();
// Load the selected bitmap file
HBITMAP hBitmap = (HBITMAP) :LoadImage(AfxGetInstanceHandle(),
m_sBitmap, IMAGE_BITMAP, 0, 0,
LR_LOADFROMFILE | LR_CREATEDIBSECTION);

// Do we have a valid handle for the loaded image?
if (hBitmap)
{
// Delete the current bitmap
if (m_bmpBitmap.DeleteObject())
// If there was a bitmap, detach it
m_bmpBitmap.Detach();
// Attach the currently loaded bitmap to the bitmap object
m_bmpBitmap.Attach(hBitmap);
}
*/the function to load the image end here

// But I used this function to load the image
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);

// Invalidate the second dialog window
m_dlgImage.Invalidate();
}
}

// ImageDialog.cpp : implementation file
void CImageDialog::ShowBitmap(CPaintDC *pdc, CWnd *pWnd)
{
// Convert the pointer to a pointer to the main dialog class
CImageDlg *lpWnd = (CImageDlg *)pWnd;
BITMAP bm;
// Get the loaded bitmap
lpWnd->m_bmpBitmap.GetBitmap(&bm);
CDC dcMem;
// Create a device context to load the bitmap into
dcMem.CreateCompatibleDC(pdc);
// Select the bitmap into the compatible device context
CBitmap* pOldBitmap = (CBitmap*)dcMem.SelectObject(lpWnd->m_bmpBitmap);
CRect lRect;
// Get the display area available
GetClientRect(lRect);
lRect.NormalizeRect();
// Copy and resize the bitmap to the dialog window
pdc->StretchBlt(10, 10, (lRect.Width() - 20),
(lRect.Height() - 20), &dcMem, 0, 0,
bm.bmWidth, bm.bmHeight, SRCCOPY);
}

void CImageDialog::OnPaint()
{
CPaintDC dc(this); // device context for painting

// Get a pointer to the parent window
CImageDlg *pWnd = (CImageDlg *)GetParent();
// Do we have a valid pointer?
if (pWnd)
{
// Is there a bitmap selected and loaded? I didin’t use this function
//if (pWnd->m_sBitmap != "")
// I use this function to Display the image
ShowBitmap(&dc, pWnd);
}
}
what should I do if I don’t use the function (pWnd->m_sBitmap != "") .
Thanks a lot of for helping

Kathrin

Confused | :confused:

Christian Graus2-Jul-01 17:38

Christian Graus

2-Jul-01 17:38

// Delete the current bitmap
if (m_bmpBitmap.DeleteObject())
// If there was a bitmap, detach it
m_bmpBitmap.Detach();

Why do you delete the bitmap and then detach it ?

In any case, if you want to write an imaging program, buy Windows Graphics Programming by Feng Yuan.

As to your question - why can't you check if the filename is valid ? I'd probably suggest that if there is a possibility that your program does not have a bitmap loaded, that this is a flaw to start with, or are you using this filename for saving ? If the former, you could instead check that the bitmap itself is valid. The easiest way to do that is to make it a pointer and check if it is NULL ( don't forget to set it to NULL to start with ).

I'm sorry if I've missed the point, it's great you posted some code in reference to your question, but there is so much code that I'm not sure what you're asking.

Do I read this correctly that your program is dialog based and has two dialogs open ?

Final comment - Hungarian notation can be a bit redundant - m_bmpBitmap is a tautology.

Christian

#include "std_disclaimer.h"

People who love sausage and respect the law should never watch either one being made.

The things that come to those who wait are usually the things left by those who got there first.

Kathrin3-Jul-01 21:10

3-Jul-01 21:10

Thank you for your e-mail.

Yes, you're right, my program is dialog based and has two dialogs open. But I don’t think you get my point.

I remarked the function you mentioned, so my code is like this:
// ImageDlg.cpp : implementation file
void CImageDlg::OnBitmap()
{
// I used this function to load the image
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);

// Invalidate the second dialog window
m_dlgImage.Invalidate();
}

And the rest of my code is the same as my previous letter.
Now, can you tell me what’s wrong with my program?
Thank for your help.

Kathrin
Smile | :)

Erik Thompson3-Jul-01 7:28

Erik Thompson

3-Jul-01 7:28

Kathrin,

If you don't want to change too much of the code, update the oinit dialog method to include the m_bmpBitmap line. OnBitmap should only have the Invalidate line; comment out everything else in the OnBitmap method. Your child dialog window to which the painting is done should be as you have it in your thread posting.

BOOL CImageDlg::OnInitDialog()
{
//...
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);
return TRUE;
}

void CImageDlg::OnBitmap()
{
// COMMENT out all other code.
m_dlgImage.Invalidate();
}

void CImageDialog::OnPaint()
{
CPaintDC dc(this); // device context for painting
// Get a pointer to the parent window
CImageDlg *pWnd = (CImageDlg *)GetParent();
// Do we have a valid pointer?
if (pWnd)
{
ShowBitmap(&dc, pWnd);
}
}

This assumes that the dialog resource was loaded correctly. The Bitmap button on the application window then turns into a refresh button.

Cheers,
-Erik
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My thoughts are my own and reflect on no other.

Kathrin3-Jul-01 22:00

3-Jul-01 22:00

Thank you for your response, I tried, and it works.
Now, what I want is to have a bitmap shown after I clicked a certain button which works as a trigger.
On the codes written in my previous letter, I put the trigger named onBitmap. That’s why I tried to load the image on the function : void CImageDlg::OnBitmap().
Thanks again for your help. Do I do it right, or do you have any other idea on how I can accomplish it.
Smile | :)

Erik Thompson4-Jul-01 7:24

Erik Thompson

4-Jul-01 7:24

In your main dialog class add a member variable of BOOL m_bShowImage. In your main dialog OnInitDialog initialize m_bShowImage to FALSE. In your main dialog OnBitmap method set m_bShowImage to not itself which will act as a toggle and call the secondary dialog Invalidate. In you OnPaint method for the second dialog where you originally had a string check for the file name replace that with the if (m_bShowImage == TRUE). Like below

class CImageDlg :CDialog
{
//...
public:
BOOL m_bShowImage;
};

BOOL CImageDlg::OnInitDialog()
{
//...
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);
m_bShowImage = FALSE;
return TRUE;
}

void CImageDlg::OnBitmap()
{
// COMMENT out all other code.
m_bShowImage = !m_bShowImage; // Acts as toggle.
m_dlgImage.Invalidate();
}

void CImageDialog::OnPaint()
{
CPaintDC dc(this); // device context for painting
// Get a pointer to the parent window
CImageDlg *pWnd = (CImageDlg *)GetParent();
// Do we have a valid pointer?
if (pWnd)
{
if (m_bShowImage)
ShowBitmap(&dc, pWnd);
}
}

Cheers,
-Erik
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My thoughts are my own and reflect on no other.

Kathrin4-Jul-01 19:08

4-Jul-01 19:08

Well, thanks for your suggestion, I tried it and it works.
Now, can I bother you again? I hope I can……..(please…………… Smile | :)

)
I’m sorry because I forgot to tell you that I what want is to have a bitmap shown after I input a code (in code named : m_strNumber) and I clicked a certain button which works as a trigger.
That’s why on the codes written in my previous letter I tried to load the image on the function : void CImageDlg::OnBitmap().
So my code looks like this:
void CImageDlg::OnBitmap()
{
// Load the image
UpdateData(TRUE);
if(m_strNumber=="001")
m_bmpBitmap.LoadBitmap(IDB_BITMAP1);
else if(m_strNumber=="002")
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);

m_bShowImage = !m_bShowImage;
// Invalidate the second dialog window
m_dlgImage.Invalidate()
}

I have a strange result that if I input the number = 001, and then clicked the OK button, the bitmap is showing perfectly. But then, if I change the number to 002 and clicked the OK button without exiting my apps, my apps will results an error.
How did it happened, did I missed something again? Or do you have any other idea on how I can accomplish it.
Thanks again for your help.

Kathrin
Smile | :)