4年前Win32で空のプロジェクトから少しずつ勉強して書けるプログラムを増やしています。今は、MessageBoxの柔軟性を高くするために、引数に合わせて正しくメッセージボックスを生成させようと思っています。MB_OK);上記で正しく動作するのは1だけで、4はMessageBoxAを使えば動作させられるのですが2、3は既存の関数では対応できず、引数によって使う関数を変えるのも面倒なので、オーバーロードにてこれらを包括した関数を作成しようとしましたが、引数に全角文字を使うと文字化けしてしまいました。(下記プログラムのように半角英数では期待通りの動作になります)全角文字を使用しても文字化けしないようにしたいのですが、どのように変えれば良いでしょうか?正直、TEXT("~~")の中身が良くわかっていないので、理解が追いつくか不安ですがよろしくお願いします。Express」です。(下記プログラムのように半角英数では期待通りの動作になります)すいません、呼出し部分のプログラムを記載し忘れていました。型のLPCTSTR/LPTSTRは、プロジェクトの設定により変わります。全般-文字セットがUnicodeになっていればLPCWSTR/LPWSTR、マルチバイトになっていればLPCSTR/LPSTRに切り替わります。何も設定した覚えがない場合はUnicodeになっていますので、1しか正常に動かないのは当たり前です。Win32API関数も同じですよ。MessageBox関数は、Unicodeの場合MessageBoxW関数、マルチバイトの場合MessageBoxA関数を使用するように切り替わります。char*/char*=LPCSTR/LPSTRなので問題ない)。単純に文字列コピーしても動きません。MultiByteToWideChar関数WideCharToMultiByte関数などの関数を使う必要があります。char*ではなくchar*型にしているのは気に入らないなあ。lstrlenWじゃダメだったのだろうか?さらにまずいことには、lengthの計算(11行目など)においてi1は高々2559の値しかとらないので、lengthは高々2560の値しか取りません。sizeof(char)は1だったはずなので、title[2560]やtext[2560]へのアクセスは確実に確保された領域の範囲外へのアクセスになります。ひどいことには、mallocは確保した領域を0で埋めないため、textやtitleに格納した文字列の後ろにゴミが入る可能性が高いです。【訂正】文字列の長さ+1、すなわち終端文字までコピーしているようでした。mallocの戻り値をチェックしていないことも気になりますが...範囲外アクセスや文字列の終端を格納していない問題に比べたら些細なことでしょう。MB_OK);上記で正しく動作するのは1だけで、4はMessageBoxAを使えば動作させられるのですが2、3は既存の関数では対応できず、引数によって使う関数を変えるのも面倒なので、オーバーロードにてこれらを包括した関数を作成しようとしましたが、引数に全角文字を使うと文字化けしてしまいました。(下記プログラムのように半角英数では期待通りの動作になります)すいません、呼出し部分のプログラムを記載し忘れていました。MB_OK);まず、textやtitleの型を指定してください。4年前この件に関しては、charじゃなくてTCHARを使えば解決するのではないでしょうかね。TEXTマクロと同様にプロジェクトの設定で切り替わる文字型です。理解不足のようでコンパイルが通らなかったので、今回は諦めました。そこで、汎用性を放棄して、強制的にマルチバイトで扱うためにTEXT("AAAあああ")をすべて"AAAあああ"に変えたところMessageBoxではNGでしたが1~4すべてMessageBoxAで期待通りの動作になりました。(MessageBoxがうまくMessageBoxAとMessageBoxWに切り替わっていない?)ともかく、汎用性を放棄すれば、char型に格納した文字列も、任意の""に括られた文字列もMessageBoxAで呼び出すことには成功したので、本件はこれで解決という事にさせてもらいます。っくす様が冒頭に記載して下さっている内容が理解できていない事が根本的な問題かと思いますのでこれについては今後参考書などで勉強していこうと思います。(ネットでいくつかのサイトを読んでみましたが、いまいち理解できずでした)ありがとうございました。char*ではなくchar*型にしているのは気に入らないなあ。本件の内容とはずれている気がします。あと、わざわざ&text[0]って書かずに、textって書いても(textがchar*型なので)全く同じ値になると思うのだが、これは好みかな?好みです。lstrlenWじゃダメだったのだろうか?メモリ確保について勉強不足でして、どの程度で区切るのが効率的なのかがわからなかったため1つの基準である256をベースとして、これでは必要な文字数を確保できない可能性が高かったためその10倍に設定しました。この場合32767で区切った方がメリットが大きい(もしくは2560で区切る意味が無い)のでしょうか?本件は「解決」とさせて頂きますが、引き続きもしよろしければ初心者にも分かるように教えていただけると幸いです。まずいことには、lengthの計算(11行目など)においてi1は高々2559の値しかとらないので、lengthは高々2560の値しか取りません。sizeof(char)は1だったはずなので、title[2560]やtext[2560]へのアクセスは確実に確保された領域の範囲外へのアクセスになります。title[2560]を静的確保したいた時の名残です(しかもそれでもtitle[2559]までしかダメ)。受け取った文字列が想定以上の長さの場合、'\0'が代入されない事を懸念しての事であり、静的に確保した場合は受け取った文字列に関係なく、保険として最終文字を'\0'としていたのですが、動的確保に変えた段階でそれらを考慮しておりませんでした。textやtitleの型を指定してください。すいません、宣言のところも含めておくべきでした。」としてコンパイルが通らなかったため、今回は汎用性を放棄してTEXT("AAAあああ")の部分を"AAAあああ"に変更しました。MessageBoxAを使用することで関数を切り替える手間を省略する方法を採る事にしました。簡潔なご指摘で、知識不足ながら動作確認を行いやすかったので凄く嬉かったです。ありがとうございました。APIは互換性のために残されていると言っても良いもので、変換するならワイド版に持っていくべきと思います。TCHARを使って解決できる状況ならば、そもそもオーバーライドする必要がありません。ミクプラは自由にリンクできます。