MFC相談室 mfc23d.dll [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/09/21(水) 00:20:48.44

Microsoft Foundation Classライブラリ専用スレです。

■MFC相談室 mfc21d.dll■
http://hibari.2ch.net/test/read.cgi/tech/1250919279/l50
■MFC リファレンス■
http://msdn.microsoft.com/ja-jp/library/d06h2x6e(v=VS.100).aspx

**デフォルトの名無しさん** · 2020/09/16(水) 22:23:13.67

>>618
具体例をあげよ

**デフォルトの名無しさん** · 2020/09/17(木) 04:59:15.63

>>621
Visual Studioが使えなくなる。

**デフォルトの名無しさん** · 2020/09/17(木) 12:47:47.90

Visual Studio で造れるもの
Tcl/Tk
wxWidgets
Qt
その他

**デフォルトの名無しさん** · 2020/09/23(水) 14:11:24.89

「かんたんVisual C++ 改定2版」という本を見つけたのだが、ダイアログベースのアプリの説明がほとんどでSDIとMDIの説明はちょっとだけ。

MFC Tutorial
https://www.tutorialspoint.com/mfc/index.htm

上の海外のページでもダイアログベースの説明なんだよなあ。

SDIやMDIを好きに変更できるようにならないと業務に使えないのだが。
もしかしたらCMultiDocTemplateクラスのせいで自由にレイアウト変更できないの？

**デフォルトの名無しさん** · 2020/09/23(水) 14:13:15.44

>業務

ωωω

**デフォルトの名無しさん** · 2020/09/23(水) 15:16:33.25

結論的に言えば、以下の本を買えば、昔ながらのMFCのSDI/MDIプログラムは学べるはず。
他にも、4種類くらいの本があり、ダイアログベースのプログラミングなどに詳しい本もあるので
そっちもあわせて見れば、かなりの事が分かるはず。

かんたん Visual C++ [改訂2版] (プログラミングの教科書) (日本語) 単行本（ソフトカバー）
Visual C++の基本の文法を完全網羅。イラスト図解でやさしく解説したMFCの教科書です
2017年10月13日発売, 堀義博著, A5判／560ページ, 定価（本体2,980円＋税）

技術評論社のページに以下の様な目次が出ている :

https://gihyo.jp/book/2017/978-4-7741-9259-8#toc

11章　SDI/MDIアプリケーション
11-01　SDI/MDIアプリケーション
11-02　MDIプロジェクトを作成する
11-03　MDIで画像ファイル表示アプリケーションを作成する

もあるし、
10-01　ダイアログデータエクスチェンジ
10-02　メッセージの処理
10-03　ダイアログデータバリデーション
もあり、見てみたら、MFCの基本的な使い方はかなりちゃんと書いてあるようだ。

5章　コードウィザード
5-01　クラスウィザード
5-02　メンバー関数の追加
5-03　メンバー変数の追加

6章　デバッグ
7章　MFCの基本的なクラス
8章　コモンコントロール
9章　デバイスコンテキスト

**デフォルトの名無しさん** · 2020/09/23(水) 15:37:00.18

>>627
>>625を読んでないなw

**デフォルトの名無しさん** · 2020/09/23(水) 15:45:17.15

>>628
この本は、ちゃんと、1つの章を割いているので、別の本のことかと思った。
そもそも、MFCのSDI/MDIは、そんなに高機能ではないので、質問者は勘違いしている
かも知れない。
MFCは、ダイアログベースにすると、割とIDEの機能が強く働いて、
C#のWinFormsと似たようなポトペタ的なプログラミングに近くなるが、
SDI/MDIは、メニュー以外には余り支援が無い。
SD/MDIでも、ダイアログを使えば、ポトペタ的になる。
というか、「Win32 Control」と呼ばれているものは、もともと、
ダイアログに入れた場合にちょうどよく機能するように設計されている。
だから、「ダイアログリソース」なるものがあるが、それ以外では、
独自に全て座標やサイズを指定して出すしかない。

**デフォルトの名無しさん** · 2020/09/23(水) 15:49:14.69

>>629
普通、どのアプリを見ても分かるが、メインメニューとツールバーがあり、
一行のテキストフィールド(EditBox)や、ボタン、チェックボックス、
コンボボックスなどは、全てダイアログの中に収められていることが多い。
だから、SDI/MDIアプリも、IDEの支援は、ダイアログ以外は、
メニューとツールバーが中心で、後は関数の作製・削除、検索、置換、
デバッグなどに限定される。
というわけで、SDI/MDIプログラムを学ぶと言っても、ポトペタ的な
ものは、ダイアログの部分を学べばよいだけ。
そしてそれに関係するのが、ダイアログデータエクスチェンジ(DDE)。

**625** · 2020/09/23(水) 16:22:00.82

>>629-630
625です。
その本を立ち読みしたのですが、SDI/MDIの部分は本当にペラペラです。

ダイアログベースだとメニューがないので、あれは実用にならないのではないでしょうか？
自分的にはSDI/MDIが実用アプリの基礎であれを改造しないと実用にならないと思っていたのですが、違うのですか？

個人的にはメニューがあって、ウィンドウにツリービューが表示されているようなものを作りたいのですけど、調べてもちっとも分からないんですよね。
最悪、Win32で作るしかないとは思っていますが。

**デフォルトの名無しさん** · 2020/09/23(水) 17:53:31.35

wxWidgets

**デフォルトの名無しさん** · 2020/09/24(木) 09:52:03.03

>>631
>個人的にはメニューがあって、ウィンドウにツリービューが表示されているようなものを作りたいのですけど、調べてもちっとも分からないんですよね。
VS2019だと、MFC-Projectを作成する際に「Visual Studio」を選ぶと最初から
サンプルとして利用できるプロジェクトが作られる。
Windowsプログラムでは、作り方は、サンプルを参考にして、そこをヒントに
分からない部分をネットで検索して調べるのが基本。
全くサンプルが無いと作るのはほとんど不可能な場合があり、
「SDK」と呼ばれているものの意味や目的の50%は、サンプル集であると言っても
過言ではない。

**デフォルトの名無しさん** · 2020/09/24(木) 09:58:05.46

>>631
>ダイアログベースだとメニューがないので、あれは実用にならないのではないでしょうか？
>自分的にはSDI/MDIが実用アプリの基礎であれを改造しないと実用にならないと思っていたのですが、違うのですか？
ダイアログベースアプリも結構見かけて、C#のWinFormsアプリとMFCのダイアログアプリ
は、言語が違うだけで理念はほぼ同じ。
しかし、本格的な「アプリ」を作りたければ、SDI/MDIプロジェクトをベースに作るのが基本。
「ダイアログベース」にしなくても、ダイアログベースアプリの作り方で学んだ知識は、
SDI/MDIアプリでも生かせる。
SDI/MDIアプリの中で、ダイアログを生成することが出来、その時に、ダイアログベースアプリ
と同様の作法が使えるから。
ウィンドウにツリービューを入れたい場合、CTreeViewまたは、CTreeCtrlを使う。

**625** · 2020/09/24(木) 12:34:17.45

>>634
>ウィンドウにツリービューを入れたい場合、CTreeViewまたは、CTreeCtrlを使う。

CTreeViewは知っているけど、VSが生成したプログラムにどうやって入れるのかがわからないんですよ。
検索してもちっとも出てこない。英語で検索しても出てこない。
日本語でも英語でもダイアログベースの解説しか出てこないので、ツールボックスからツリービューをダイアログにドラッグ・ドロップしてしか出てこない。
こんなのじゃ役に立たない！

**デフォルトの名無しさん** · 2020/09/24(木) 12:49:59.87

>>635
VSが生成する前のアプリケーションウィザードのところで
基本クラスをCViewからCTreeViewに変更できる

**625** · 2020/09/24(木) 13:35:34.64

>>636
できましたけど、VIEW/DOCモデルを選択した時しかできないですよね。
VIEW/DOCモデルを使うと、ファイル読み込みと書き込みの対称関係が強制されるので、これも困るというか。
自分が作りたいアプリは、メモリに絶対入らない巨大なファイルを少しずつ処理してエクスポートするものなので、読込・保存の概念がない。
やはりMFCは使わない方がいいのだろうか。Win32にした方がいいかもしれない。
どうしてMFCはWin32みたいに部品を組み合わせていくように作れないのだろう。

**デフォルトの名無しさん** · 2020/09/24(木) 13:52:29.54

class設計がタコだから
class library と名乗るのがそもそも詐欺
ただの win32api wrapper あるいは劣化版

**625** · 2020/09/24(木) 14:08:51.69

>>638
それは一般的な見解なのでしょうか？
ここだと「Win32は手間がかかりすぎる。MFCにしないとだめ」的な書き込みも多々見かけるので混乱します。

**デフォルトの名無しさん** · 2020/09/24(木) 14:30:44.47

>>637
別に、ドキュメント/ビューの仕組みを使ったら
ファイル全体をメモリ上に読み込まないといけないわけではないけど、
そうなると、MFCの標準の処理をいろいろオーバーライドすることになるので、
内部の仕組みを理解する必要が出てくる。

ドキュメント/ビューが抵抗あるなら、使わずにSDIを作成して、
CChildViewの中にCTreeCtrlを載せたりすることもできるけど。

**デフォルトの名無しさん** · 2020/09/24(木) 14:31:42.32

>>637
Doc,Viewモデルは、MFCを使うと必ず伴うが、個人的にはほとんど無視してプログラム
している。
無視すると言うのは、Docではなく、全てViewの中にデータを入れたらいい。
イベントを受けるのを、View,Doc,Appのうちから選べるようになっているが、
原則的には全てViewで受けると便利。
MFCは、Doc,Viewモデルで設計されていると言うが、実際には余り使い勝手がよくなくて、
1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。
なので、無視していい。

また、プロジェクトを作成後、ClassWizardで、Viewを作れるがその際、
どのViewを作るかを選べるようになっていてTreeViewも作れる。

Win32が使える人はMFCも使える。
MFCは、IDEと連携では便利なだけなので、自分で好きなようにWin32と混ぜて使っていい。
MFC自体、Win32のとても軽いラッパーに過ぎないから。
MFCはソースが付いてくるので、それを見れば、Win32との対応関係が分かる。

**デフォルトの名無しさん** · 2020/09/24(木) 14:37:46.49

>>639
MFCは、Win32の軽いラッパーであることは、標準見解。
ただし、IDEとの連携がWin32より上手くできているので開発効率は上がる。
理解するのは、実はWin32より難しくなってしまっている部分もある。
しかし、イベントハンドラやメニューハンドラをどんどん追加していく場合の
効率がとても良い。
また、新しいWindowを作る際も、ClassWizardから作るとWin32で自分で
作るより速いことが多い。
メニューにチェック記号を付けたり、グレイ表示にしたい場合も、
MFCは、CCmdUI や、ON_UPDATE_COMMAND_UI()などを自動生成できるので、
効率が良い。
また、Win32だとswitch文でメニューを処理するが、MFCだと、自動生成された関数
で処理するので、大規模なアプリの場合、コードが整理される。

**デフォルトの名無しさん** · 2020/09/24(木) 14:44:39.87

>>637
MFCの読み込み、保存の概念は、はっきり言って、型にはめられすぎていて
MSが想定した典型的なアプリ以外だと不便だから、実は無視してもいい。
それから、DocTemplateを理解するのがまた難しいが、それはなかなか避けて
通れないこともある。
基本的には、フレームワークが想定しているファイルオープンの概念を、
如何に無視して自分流にしていけるかが、MFCを使う上での重要なポイントになる。
最初は難しいが、MFCはソースがあるので、それをおっていくと、何をやっている
かが分かるので、「安全に無視する方法」を探るといい。

**デフォルトの名無しさん** · 2020/09/24(木) 15:01:57.18

Docを無視してViewだけ使うってのは俺もよくやるｗ

**デフォルトの名無しさん** · 2020/09/24(木) 15:35:28.03

>>640-644
うーむ・・・
結局、MFCが提供する仕組みを無視しないと自由にプログラムを組めないのか。
しかも安全に無視するにはMFCの仕組みを熟知しないといけないと。
そんなこと組込一筋の自分にはできそうにないなあ。
今作りたいプログラムを作ったらMFCを使うことは二度となさそうだし、やはりMFCは回避するべきだろうか・・・
頭痛いよ

**デフォルトの名無しさん** · 2020/09/24(木) 15:40:13.30

>>645
というか、「Doc,Viewはかくあるべき」という設計思想が難しいし、
それを守っても余り良いこと無いので、無視してよい、ということ。
なにも、アメリカ人の考えた思想に従う必要は無いのだから。
その当時の彼らはそれが理想だと考えたかも知れないが、それも
どんどん変化しているし、別の勢力はまた別の設計思想を持っているのだから。

**デフォルトの名無しさん** · 2020/09/24(木) 15:50:00.97

>>645
いやいや、別に邪道なことをしているわけではない
Docを使う／使わないを任意に選べるようになっているというだけ

**デフォルトの名無しさん** · 2020/09/24(木) 16:08:29.20

>>645
無駄に覚えることが増えるし
しかもバッドノウハウで
他に何の役にも立たん
深入りする意味が無い

**625** · 2020/09/24(木) 16:14:40.31

>>646-647
>>640に「そうなると、MFCの標準の処理をいろいろオーバーライドすることになるので、内部の仕組みを理解する必要が出てくる。」と書かれているので、難しいはずです。簡単に無視できないはず。

そもそも組み込みの技術者なので、PCのプログラミングは「ついで」的にしないといけない。
PCのプログラミングに力を入れると評価が下がってしまう。
そうなると知識量が必要なMFCは避けないといけない。やはりWin32にするべきか。

>>648
バッドノウハウ＝MFCってことですか？

**デフォルトの名無しさん** · 2020/09/24(木) 16:33:16.74

>>649
> SDIやMDIを好きに変更できるようにならないと業務に使えないのだが。
こう言ってた人が

> PCのプログラミングに力を入れると評価が下がってしまう。
> そうなると知識量が必要なMFCは避けないといけない。やはりWin32にするべきか。
こう言い出す意味がよくわからんのだが

組み込みが本業の人がMFCを何に使うんだろう
基板から送られてくるデータを可視化とか？
シミュレーションや回路設計は専用ソフト使うだけだし

**625** · 2020/09/24(木) 16:40:57.87

>>650
要は力を入れないで業務で使えるGUIのプログラミングをしないといけないということです。
何も分かっていない上司に言われてやっているので、仕方がないのです。

>組み込みが本業の人がMFCを何に使うんだろう

企業秘密なので、詳細は書けない。
データの可視化の一種と言っておく。

**デフォルトの名無しさん** · 2020/09/24(木) 16:49:31.37

>>651
でも、プロジェクト作成時に「Visual Studio」を選ぶと、プロジェクトを作製した直後から、TreeViewが既に出ているよね。
それをいじくれば、TreeViewは制御できる。
後はメニューに対するハンドラの書き方さえ分かれば、アプリは作れる。

**625** · 2020/09/24(木) 16:50:34.31

個人的にはGUIは不要だと思っているのですけどね。
現場で働く派遣社員や外注などのレベル低下でCUIのツールが受け入れられなくなっているってだけでGUIのプログラミングをやるはめになった。

**625** · 2020/09/24(木) 16:51:57.29

>>652
問題は>>649ですよ

**デフォルトの名無しさん** · 2020/09/24(木) 16:53:39.81

>>653
裏でCUIツールを起動するだけ、みたいのだとダイアログベースで充分じゃね？

**625** · 2020/09/24(木) 16:56:46.90

>>655
それは上司にダメって言われたんですよ

**デフォルトの名無しさん** · 2020/09/24(木) 17:07:39.97

いちおーSDI用のスケルトンを使って
内容的にはダイアログベースなやつにするとか
ログを記録したり終了時に使用状態をファイルに記憶させるのにDoc使いましたよって

**625** · 2020/09/24(木) 17:26:50.28

>>657
そこまでは知識不足で判断できません。
どちらにしても>>640の言うように使わない機能を無視するのも簡単ではないようですが。

**デフォルトの名無しさん** · 2020/09/24(木) 18:13:53.22

ダイアログベースがダメだと言うなら、>>640の言うように、
Doc/Viewを使わないSDIで、CChildViewに処理を全部入れてしまうのが一番シンプルでは？

**デフォルトの名無しさん** · 2020/09/24(木) 18:19:58.65

>640の前段は「ドキュメント/ビューの仕組みを使ったら」だ
ドキュメント/ビューを一切使わないのは簡単
使わないだけ

ダイアログにメニューも普通に付く
「ダイアログ　メニュー」でggr

そんなにWin32API直でやりたいならそうすればいいけど
どっちにしろ、猫でものWindows SDK編でも一通りやっといた方がいいよ
MFC使うにしても、「ドキュメント/ビュー」とかのMFC独自のとこ以外は
よく言われるようにWin32APIの薄いラッパだから

**625** · 2020/09/24(木) 18:59:32.67

>>659
そこまで判断する知識はまだなくて

>>660
>ダイアログにメニューも普通に付く

そんなことが可能なのですね。
https://www.kazetest.com/vcmemo/dialogmenu/dialogmenu.htm
それならダイアログベースでも可能かもしれません。

Win32についてはそこである程度勉強したのですが、部品を組み立てるような感覚で自由にできるので、下手にMFCに手を出すよりはマシかと思ったわけです。

**デフォルトの名無しさん** · 2020/09/24(木) 19:15:13.93

>>658
別に、Doc/Viewモデルを使っていても、ファイルは好き勝手に読み書きできるよ。
勝手にfopen()して、一部だけ読み込んだりとか普通にやってる。
Doc/Viewモデルを使うとしても、
CDocument::OnOpenDocument(const char *pszFilename)
が呼び出されたときに、fopen()して、fread()して、どこか好きな場所に
データを読み込めばよい。
CDocumentの中に読み込まなくても、グローバル変数に読み込んでも、
CViewの中に読み込んでも、好きなクラスの中に読み込んでも良い。
本当に読み込んだかどうかは、MFCのフレームワークは全く感知しないので、
好き放題出来る。

**デフォルトの名無しさん** · 2020/09/24(木) 19:16:51.84

>>661
MFCも、本等は好き放題出来る。
個人的には、大改造して使ってる。

**デフォルトの名無しさん** · 2020/09/24(木) 19:36:48.02

>>662
>>663
お二人のようになれればいいのですけどね

**デフォルトの名無しさん** · 2020/09/24(木) 20:48:36.72

>>641
単一ドキュメント複数ビューはできないわけじゃないよ。
DocTemplateを派生させる必要があるというだけ。

**デフォルトの名無しさん** · 2020/09/24(木) 21:07:02.77

>>664
「MFCによるWindowsプログラミング」ISBN 475611749X

首都圏在住なら国会図書館で見てこい
ttps://iss.ndl.go.jp/books/R100000002-I000002930291-00

田舎住まいなら尼(ISBNで検索)で\32,580で売ってるから上司に頼んでこれ買ってもらえ

**デフォルトの名無しさん** · 2020/09/24(木) 21:20:33.40

>>641
> 1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。
CDocumentには、UpdateAllViews()という名前の関数があるように、
複数のビューを関連付けられるぞ。

>>662
わざわざDoc/Viewを選んでおいてDocクラスを放置するくらいなら、
印刷プレビューでも使わない限り、Doc/Viewを使わない形式で
CMainFrameとCChildViewだけを使うほうが楽だと思うけどな。

**デフォルトの名無しさん** · 2020/09/24(木) 21:45:13.19

SDIでもCFromViewしか使ったことないナ

**デフォルトの名無しさん** · 2020/09/25(金) 00:33:44.17

MFC は、数十年前w
Jeffrey Richter とかの時代

Win32 API を、クラスにまとめたもの。
メニューバーも作れる

MFCって、まだ存在するのか

**デフォルトの名無しさん** · 2020/09/25(金) 00:48:06.02

WindowsでC++とVisual Studioを使ってデスクトップのプログラムするなら、
今でもMFC以外の選択肢はほぼ無いはずだが、

**669** · 2020/09/25(金) 02:04:10.72

かんたん Visual C++［改訂2版］、堀義博、2017

この本では、.net か、managed C++ か、interop か何かを使っていた。
でも結局、このやり方も、流行らなかったのか

MFC ではなかった気がする

**デフォルトの名無しさん** · 2020/09/25(金) 09:17:50.44

>>667
> > 1つのDocに対して複数のViewなどをしたくても多分、設計上は出来ない。
>CDocumentには、UpdateAllViews()という名前の関数があるように、
>複数のビューを関連付けられるぞ。

スマソ。記憶違いがあった。
1つのDocに対して複数のViewは、一応は関連付けられる。
しかし、それはどれも1つのCFrameWndの中に入れておかないといけなくなって
しまっているため、WzEditorの「テキストの二重化」のように、
1つのテキストファイルの別の場所を複数のFrameWndの中に表示するという
ようなことが、MFCでは基本的に出来ないハズ。

**デフォルトの名無しさん** · 2020/10/16(金) 18:08:33.74

CTreeCtrlクラスでツリー表示の文字色を部分的に変えたいけど、Windows SDKみたいにカスタムドローしないと無理ゲー？

**デフォルトの名無しさん** · 2020/11/20(金) 05:11:03.85

実際にウィンドウ上に表示している画面をBitmapに画像保存するんじゃなくて、
表示させないで、データだけを元に、連続的に画像保存するってどうやるのかな？

例えば、ボタン１つで、円の位置を連続的に動かしたデータを、
それらをわざわざ画面に表示させないで、連続的に画像に保存したいんだけど、
やり方がわからない。

**蟻人間** ◆T6xkBnTXz7B0 · 2020/11/20(金) 05:14:55.72

>>674
CreateCompatibleDC(NULL)とCreateDIBSectionだろう。DIBビットマップオブジェクトを作成し、DCでそれを選択し、DCで描画する形になる。

**デフォルトの名無しさん** · 2020/11/21(土) 18:08:17.32

>>675
ありがとう、教えてもらったキーワードをググってみます。

**デフォルトの名無しさん** · 2021/01/18(月) 23:31:44.08

DialogにCMFCFontComboBoxを張り付け
プロパティの「フォントを使用して描画」をTrueにすると
コンボボックスの行の高さを無視して大きく描画されます。
XX明朝とXXゴシックが縦に重なって描画される感じです。
(ディスプレイ設定で拡大表示している場合のみ)
以前は普通に表示されていた気がするのですが。
良いアイデアがあればお願いします。

**デフォルトの名無しさん** · 2021/01/21(木) 23:11:43.50

あきらめて素のComboboxで作り直しました。

**デフォルトの名無しさん** · 2021/02/19(金) 22:39:02.63

>>439
> C++Nativeの今風なGUIライブラリ作って欲しいわ

禿しく同意

**デフォルトの名無しさん** · 2021/02/20(土) 00:53:43.48

WinUI3ってc++で書かれてるからc++ nativeじゃね??

**デフォルトの名無しさん** · 2021/02/21(日) 22:41:37.64

>>679
それだけのことなのにそれをやらないマイクロソフト

**デフォルトの名無しさん** · 2021/02/22(月) 07:01:41.68

Direct3Dは違うのか？

**デフォルトの名無しさん** · 2021/03/01(月) 23:14:22.24

昔あったCFrameWndのLoadBarStateとSaveBarStateは
何に置き換わったのでしょうか？
CMF…系のツーツバーやステータスバーでは保存＆復元されないようです。

**デフォルトの名無しさん** · 2021/03/26(金) 13:13:22.16

MFCより先進的なGUIフレームワークを使いたいならQtとかwxWidgetsを使えってことなのかねえ？

**デフォルトの名無しさん** · 2021/06/19(土) 20:11:27.16

>>683
m_pszProfileNameを初期化してる？

**デフォルトの名無しさん** · 2021/06/22(火) 01:17:37.30

>680
WinUI3には期待している。

**683** · 2021/06/28(月) 15:55:19.44

>>685
レスサンクス
明示的には初期化はしていませんが
CWinApp::SetRegistryKey(...
を呼んでるのでその中でm_pszAppNameがセットされているようです。

**デフォルトの名無しさん** · 2021/06/28(月) 16:12:02.63

>>683
CWinAppEx::LoadStateやCWinAppEx::SaveStateが勝手に呼ばれるはずだけど

**683** · 2021/06/28(月) 17:55:27.02

解決しました
VS2005で作ったソースをVS2019に移植する際
CWinAppをCWinAppEx
CToolbarをCMFCToolBar
のような作業をやったんだけど
CMainFrameからCFrameWnd::(Exなし)の関数を呼んでたのが原因でした
お恥ずかしい。レスくれた方、ありがとうございました。

**デフォルトの名無しさん** · 2021/09/15(水) 12:15:47.57

>>684
WinUI 3がネイティブ
XAMLの部分はC++コードになる

**デフォルトの名無しさん** · 2021/09/15(水) 21:06:18.05

WinUIは普通にXAML使うが。

**デフォルトの名無しさん** · 2021/09/16(木) 19:46:16.94

WPFでもXAMLからコード吐いてるぞ？

**デフォルトの名無しさん** · 2021/09/16(木) 22:38:06.15

bamlになるだけでコードを吐いたりはしないと思うが？.xaml.cs と混同してる？

**デフォルトの名無しさん** · 2021/09/19(日) 17:56:08.37

そうか勘違いか

**デフォルトの名無しさん** · 2021/09/25(土) 10:57:19.73

せめてダークモードのテーマ用意して下さい

**デフォルトの名無しさん** · 2021/10/30(土) 10:54:38.33

BCGのほうはダイアログや埋め込みスクロールバーもダークテーマにできるんだよなぁ

**デフォルトの名無しさん** · 2022/03/15(火) 08:26:51.33

BCGはロシアのセンペテロブルグだったね。
ドル建てで売ってるからウクライナ侵攻の対ロ経済制裁の影響を受けて倒産とかはなさそうだな。

**デフォルトの名無しさん** · 2022/03/31(木) 10:44:02.36

>>697
VisaやMasterのカード決済ができなくて、売れないのでは？　ロシア国外のWeb
サイトで決済して、ドルをロシアへ送金しようにも、SWIFTからの排除で銀行間
送金もできないし。

**デフォルトの名無しさん** · 2022/04/02(土) 21:39:19.21

>>698
それもそうか～。次の更新料支払いまで１０ヵ月近くあるけど、どうなるのかなぁ。
BCGライブラリはMFCでアプリ作るならやっぱり便利だし、メンテ続けてほしい。

**デフォルトの名無しさん** · 2022/04/03(日) 10:10:08.68

BCGは次のバージョンでPer Monitor DPIに対応すると予告していて、ちょっと興味ある

**デフォルトの名無しさん** · 2022/04/28(木) 07:46:47.14

BCGは新バージョンのベータ版アナウンスしたし、経済制裁の影響は大してないのかも。

**デフォルトの名無しさん** · 2022/05/19(木) 18:06:24.38

ツベルクリン反応

**デフォルトの名無しさん** · 2022/06/01(水) 11:16:30.11

マイクロソフト社がフライドチキン業界に進出したらどんな略称になるんだろう？

**デフォルトの名無しさん** · 2022/06/05(日) 21:36:12.13

サッカークラブも含めてMSFCの可能性もあり得た

**デフォルトの名無しさん** · 2022/06/27(月) 13:08:04.25

mfcのactivexコントロールの良書教えて下さい

**デフォルトの名無しさん** · 2022/10/26(水) 22:05:25.04

MFCで画像閲覧ソフトを作成しています。
ウィンドウのサイズを変更すると画像が消えてしまいます。
なぜなのかさっぱり検討が付きません。

https://ideone.com/Gn0AsK

ウィンドウのサイズを変更したときにOnPain()が呼ばれることは確認済みです。
また、OnPaint()内の
cbmp = CBitmap::FromHandle(m_image);
の部分を
CImage image;
image.Load("画像データ");
cbmp = CBitmap::FromHandle(image);
のように決め打ちで画像データを表示すると画面サイズを変更しても画像が消えません。

なにか良い手はないかご提示宜しくお願い致します。

**706** · 2022/10/26(水) 22:08:37.07

すいません、環境を書くのを忘れていました。

Windows 10 Home 22H2 (64bit)
Microsoft Visual Studio Community 2019 Version 16.11.20

何卒宜しくお願い致します。

**デフォルトの名無しさん** · 2022/10/27(木) 01:28:58.14

「mfc onpaint WM_PAINT」で検索してみれば？

MFC とか、こういうのは初心者がやるものじゃない。
たぶん、仕組みを理解するだけでも、10年以上掛かる

**デフォルトの名無しさん** · 2022/10/27(木) 03:07:34.48

良い手も何も、そういうものだと思うしかない
OnPaint()で描けばいいだけ
いつウインドウがinvalidateされるのか、アプリケーションプログラマが完璧に把握することはたぶんできないし
しても意味はあまりない

**デフォルトの名無しさん** · 2022/10/27(木) 05:57:41.65

10年のうち、もう8～9年経っている感じだね

**デフォルトの名無しさん** · 2022/10/27(木) 22:03:00.16

>>708->>10
レスありがとうございます。

そういうものなのですね。
そういうものだと思って諦めます。
ありがとうございました。

**デフォルトの名無しさん** · 2022/10/27(木) 22:03:59.35

>>ミスりました…
>>708-710

**デフォルトの名無しさん** · 2022/10/31(月) 11:29:06.13

>>706
そもそも、
cbmp = CBitmap::FromHandle(m_image);
で取得したものを
cbmp->DeleteObject();
で破棄しているのが原因では。

これだと1回目の描画のときにm_imageが破棄されて、
2回目以降は描画されないかと。