C(MFCを使用しない)でアプリを作ったのですが
ダイアログボックス内のリストボックスで
表示させるデータが横幅より大きくなったら
水平スクロールを出したいのですがプロパティの
水平スクロールにチェックをつけても出ません!!!
API関数を使って水平スクロールを出す方法を
教えてください。。至急。。どうぞよろしく
お願いします。

このQ&Aに関連する最新のQ&A

A 回答 (2件)

ちょっと遅いかな…



リストボックスにLB_SETHORIZONTALEXTENTメッセージを送ってスクロール幅を設定してやれば出てくるはずです。
    • good
    • 0

CreateWindow()関数のウィンドウスタイルパラメータに"WS_HSCROLL"を付ければでませんか?



CreateWindow()関数の詳細な使い方や、引数の指定の仕方はMSDNライブラリやAPI参考書籍で確認してください。
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QMFCとWIN32API

はじめまして、コンピューターを勉強し始めた学生です。最近OSについての基本的な勉強を始めたのですが、ちょっとAPIのところで分らなくなりました。MicrosoftのWIN32とMFCは全くの別物なんですか?どちらもWindowsのSoftware開発に関わりが在りそうだとは思っているのですが...

何かとんでもない間違った質問をしている様な気もするのですが、誰か知っている人教えてください。

Aベストアンサー

Win32はWindows9x、MeやNT、2000、Xpに実装されているAPIです。それ以前はWin16やWin32sといったものを使っていました。
APIはアプリケーションレベルから使用する事のできる、一番下の層で(ホントは違います。ホントはDeviceIOControl()でVxDの機能を使ったり出来ます。Win9xやMeではKernel書き換えて好き勝手出来るし)、この層までを用いてアプリケーションを作成すればWin32レベルでも互換性を確保する事が出来ます。
(建前(笑) ホントに互換性を維持するためにはこの中でも非互換APIを使わないようにし、挙動の違うAPIも使わない用にするか挙動をあわせるコードを書く必要があります。システム周りのAPIではNT系と9x系では互換性がほとんどありませんし(i.e. Toolhelp32系APIとPSAPI系APIとか・・・2000では両者とも使えるようになりましたが)、GDI系APIも微妙に違います。後はUnicode系のサポートも。)

それに対してMFCはWin32API(昔はWin16サポートしてた頃も)をラッピングしたクラスライブラリで(あれを「クラス」ライブラリというのはちょっと心苦しい・・・)ソフトウェア開発において工数を減らし、プログラムを見通し良いものにするものです。
一昔前はBorlandのOWLというものもありましたし、最近だとC++ Builderの(DELPHIからの移植?)VCLといったものもあります。

以上がWindowsに限った話です。まぁ、平たく言えばAPIというのはOSが用意するシステムサービスへのアクセス手段で、実行速度は速いが機能は一般的に貧弱。クラスライブラリはAPIを素のまま使うとさすがにきついので労力軽減のために使用するライブラリの一種、とでも考えてください(あくまで一例です。例外はいっぱいあります。たとえばBeOSのAPIなどはAPI自体がクラスライブラリとなっています。また、クラスライブラリも工数軽減だけでなく、porting(移植作業)を手助けするものもあります)。

Win32はWindows9x、MeやNT、2000、Xpに実装されているAPIです。それ以前はWin16やWin32sといったものを使っていました。
APIはアプリケーションレベルから使用する事のできる、一番下の層で(ホントは違います。ホントはDeviceIOControl()でVxDの機能を使ったり出来ます。Win9xやMeではKernel書き換えて好き勝手出来るし)、この層までを用いてアプリケーションを作成すればWin32レベルでも互換性を確保する事が出来ます。
(建前(笑) ホントに互換性を維持するためにはこの中でも非互換APIを使わないようにし、挙...続きを読む

QMFC - ダイアログボックスのPictureControlへの画像表示

はじめまして。
現在MFCにおいて、ダイアログ形式のアプリケーションを作成しています。環境はVisual Studio 2005になります。
内容はWebカメラからのキャプチャを行い、そのキャプチャされた画像をダイアログ上に配置したPictureControlへ表示するというものです。

キャプチャされた画像は、1チャネルのグレースケールでありunsigned char型の1次元配列で格納されています。よってビットマップとして表示するには自身で構造体BITMAPINFOを作成しなければなりません。現状以下のように作成したのですが、うまく表示されません。

画像サイズは 320×240 です。
PictureControlのIDを IDC_BITMAP と設定し、
画素情報が格納されている配列を m_pbit とします。

int i;
CWnd *pWnd = GetDlgItem( IDC_BITMAP );
CDC *Capt = pWnd->GetDC();
BITMAPINFO bmif;

bmif.bmiHeader.biBitCount   =8;
bmif.bmiHeader.biClrImportant =0;
bmif.bmiHeader.biClrUsed    =256;
bmif.bmiHeader.biCompression  =0;
bmif.bmiHeader.biHeight     =240;
bmif.bmiHeader.biPlanes     =1;
bmif.bmiHeader.biSize      =sizeof(BITMAPINFOHEADER);
bmif.bmiHeader.biSizeImage   =320*240;
bmif.bmiHeader.biWidth     =320;
bmif.bmiHeader.biXPelsPerMeter =0;
bmif.bmiHeader.biYPelsPerMeter =0;

for(i=0; i<256; i++){
 bmif.bmiColors[i].rgbBlue = i;
 bmif.bmiColors[i].rgbGreen = i;
 bmif.bmiColors[i].rgbRed  = i;
 bmif.bmiColors[i].rgbReserved = 0;
}

SetDIBitsToDevice(Capt->m_hDC, 0, 0, 320, 240, 0, 0, 0, 240, m_pbit, &bmif, DIB_RGB_COLORS);

グレースケール画像なので配列bmiColorsは全て同色としました。
また、PictureControlのTypeをオーナ描画など全てのTypeを試しましたが、表示されませんでした。

必ずPictureControlに描画しなければならないという決まりはないのですが、ダイアログボックスにビットマップを表示するにはPictureControlだと考え、それに表示するようプログラムを組みました。

画素情報(グレースケールの輝度情報)のみ既知である状態からビットマップをダイアログに表示するためには他に方法があるのでしょうか?
上記のプログラムにおける間違い、またその他の方法についてアドバイスを頂けたらと思います。

よろしくお願いいたします。

はじめまして。
現在MFCにおいて、ダイアログ形式のアプリケーションを作成しています。環境はVisual Studio 2005になります。
内容はWebカメラからのキャプチャを行い、そのキャプチャされた画像をダイアログ上に配置したPictureControlへ表示するというものです。

キャプチャされた画像は、1チャネルのグレースケールでありunsigned char型の1次元配列で格納されています。よってビットマップとして表示するには自身で構造体BITMAPINFOを作成しなければなりません。現状以下のように作成したのですが、うま...続きを読む

Aベストアンサー

 こんにちは。
 パレットサイズ(biClrUsedの数字)の分だけRGBQUADの配列を拡張して割り当てないといけません。
 正しくは、以下です。実際には、予め割り当てておくのが良いでしょう。

//割り当てる
LPBITMAPINFO pbmi = static_cast<LPBITMAPINFO>(::malloc(sizeof(BITMAPINFOHEADER) + (sizeof(RGBQUAD) * 256)));

pbmi->bmiHeader.biBitCount=8;
pbmi->bmiHeader.biClrImportant=0;
pbmi->bmiHeader.biClrUsed=256;
pbmi->bmiHeader.biCompression=0;
pbmi->bmiHeader.biHeight=240;
pbmi->bmiHeader.biPlanes=1;
pbmi->bmiHeader.biSize=sizeof(BITMAPINFOHEADER);
pbmi->bmiHeader.biSizeImage=320*240;
pbmi->bmiHeader.biWidth=320;
pbmi->bmiHeader.biXPelsPerMeter=0;
pbmi->bmiHeader.biYPelsPerMeter=0;

for(i=0;i<256;i++)
{
pbmi->bmiColors[i].rgbBlue=i;
pbmi->bmiColors[i].rgbGreen=i;
pbmi->bmiColors[i].rgbRed=i;
pbmi->bmiColors[i].rgbReserved=0;
}

::SetDIBitsToDevice(Capt->m_hDC, 0, 0, 320, 240, 0, 0, 0, 240, m_pbit, pbmi, DIB_RGB_COLORS);

//開放する
::free(pbmi);
--------------------------------------------------------------------------------------------------------------
強引ですが、以下の様なやり方も出来ます。

struct BMI
{
BITMAPINFOHEADER bmiHeader;
RGBQUAD arrPalette[256];
};

//キャストする
BMI bmi;
LPBITMAPINFO pbmi = reinterpret_cast<LPBITMAPINFO>(&bmi);

//ヘッダとパレットの代入をする
pbmi->bmiHeader.biBitCount=...

//使用する
::SetDIBitsToDevice(...)

//開放は必要ない

 こんにちは。
 パレットサイズ(biClrUsedの数字)の分だけRGBQUADの配列を拡張して割り当てないといけません。
 正しくは、以下です。実際には、予め割り当てておくのが良いでしょう。

//割り当てる
LPBITMAPINFO pbmi = static_cast<LPBITMAPINFO>(::malloc(sizeof(BITMAPINFOHEADER) + (sizeof(RGBQUAD) * 256)));

pbmi->bmiHeader.biBitCount=8;
pbmi->bmiHeader.biClrImportant=0;
pbmi->bmiHeader.biClrUsed=256;
pbmi->bmiHeader.biCompression=0;
pbmi->bmiHeader.biHeight=240;
pbmi->b...続きを読む

Q.Net Framework APIがあればMFCはいらないのでは?

最近Windowsプログラミングに興味を持ちましていろいろと調べている所なのですが、疑問に思ったので質問させて下さい。

質問の内容はタイトルどおりなのですが、
windowsのシステムが.Net Frameworkに統一されようとしている今、.Net Framework APIがあればMFCを新しく勉強する価値は殆どないと思うのですが、この考えは間違っているでしょうか?

例えば、下の本(実物はまだ見てません)
http://www.amazon.co.jp/exec/obidos/ASIN/4797324201/249-5720925-3989928
では「 MFCを利用したWindowsネイティブプログラムから,最新の.NETアプリケーションの作成方法まで,..」
と紹介されてますが、VC++.NETでプログラミングするのに、なんでMFC?なんて思って仕舞うのですが、MFCでないと出来ないことがあるのでしょうか?

Aベストアンサー

>.Net Framework SDK + .Net Platform SDK + VC++ Toolkit
>
>を使えば、MFCでなく、.Net Framework APIを使ってダイナミックリンクの不要のnative codeまで
>落とせるものと考えていたのですが、
>それがそもそもまちがいなのでしょうか。言い換えると、上の組み合わせではnative codeまで落とせても、
>MFCまたはWin32APIを使わなければランタイム不要のコードを生成することができないのでしょうか。

はい、現状では間違いです。.NET Framework自体が巨大なRuntimeであると思ったほうがいいでしょう。.NET FrameworkがOSに統合されて初めてそう言えます。
また、.NET Frameworkを使用するということは将来的にもnative codeはなりません。生成物はアセンブリとなります。


>Win32APIはCのライブラリ。
>MFCはVC++のライブラリ。
>VC++.NETにはその理念に相応しいライブラリで記述したいよね。

ここにも認識に誤りがありますね。

Win32APIは、Windowsのライブラリです。Cのライブラリではありません。Windowsの機能を直接使うためのものです。
インターフェイスもC的なものやC++的なもの、VBで扱いやすいCOM等さまざまです。

VC++.NETはあくまでもVC++のバージョンアップしたもので.NET Frameworkが使えるものという位置づけです。
.NET Frameworkのためだけのものではありません。

それに、VC++で.NET Frameworkの開発は他の方も回答しているとおりあまり適していません。MSは専用の言語であるC#を準備するくらいですから。

ですので、VC++.NETに適しているのライブラリが.NET Frameworkだというのもちょっと・・・という感じですね。私は、MFCやATLになると思います。


>もし、.Net Framework APIがWin32APIの完全な代替物であるのであれば
>(この点は自信がないので質問に含まれています。)

現時点では違いますね。APIを必要とする機能だらけです。MFCであってもすべてのWin32APIを包括しているわけでもありませんし。
まぁ、でも次期OSではそうなるかもしれませんが。


>これからVC++を学ぼうとする人間がMFCを学ぶ意義は、将来性の面からいってかなり薄れているのではないか?

MFCは、Windowsが存在する限り、おそらくなくならないでしょう。そういう意味であれば、将来性はあるフレームワークです。


>だとしたら、なぜ、.Net Framework APIを強調したVC++.NETの解説が見当たらないのだろう?
というくらいに弱めておきます。)

それは、.NET FrameworkがVC++の一部ではないからです。
.NET Frameworkはさまざまな言語から利用できます。C#やVB.NETの解説本が.NET Frameworkを中心に書かれているのはこれらの言語の基本となる技術が.NET Frameworkだからです。
C++は.NET Frameworkの上に成り立っているわけではないですよね。

「適材適所」という言葉を使ったのは、.NET Frameworkを使用可能か?.NET Frameworkを簡単に使えるか?ということでもあります。


>だから、せっかくVC++「.NET 」なら
>それ相応のAPIで書きたいなとみんな思わないのかな?
>それともそうしないのは何か理由があるのかな?

というくらいのレベルの人であれば、VC++での.NET Frameworkの解説を望んでいるのではなく、.NET Framework自体の解説を望むと思いますよ。

メリットは、「.NET Frameworkに対応した任意のプラットホームで実行可能」というだけではなく、「任意の言語で作成されたアセンブリも相互利用できる」こともなんですから。

.NET Frameworkを理解できる人であれば、言語に依存した単純な使い方さえわかれば、それ以上の言語に依存した解説など不要でしょうし。

>.Net Framework SDK + .Net Platform SDK + VC++ Toolkit
>
>を使えば、MFCでなく、.Net Framework APIを使ってダイナミックリンクの不要のnative codeまで
>落とせるものと考えていたのですが、
>それがそもそもまちがいなのでしょうか。言い換えると、上の組み合わせではnative codeまで落とせても、
>MFCまたはWin32APIを使わなければランタイム不要のコードを生成することができないのでしょうか。

はい、現状では間違いです。.NET Framework自体が巨大なRuntimeであると思ったほうがいいでしょう。....続きを読む

QAPIとMFC

WindowsでC言語で書けて(利用できて)無料のものがAPI、C++で使えて有料なものがMFC
だから、アマチュアプログラマーは、APIが使いこなせるのならば、APIを使ってプログラムを
書いたほうがいい

という理解で正しいでしょうか。

ここでAPIと書いたのはWin 32 APIのことです。

Aベストアンサー

有料=プロが使う物、ではないと思います。
・MFCはC++用のライブラリなので、C言語しかできないのであれば使えない。
・そもそもVisualStudioの有料版を持っていないとMFCが入っていないから使えない。
という事実があるだけかと。
なので、それなりの規模のプログラムを書くつもりであるのなら、MFCを使ったほうが保守性が高まる(はずな)ので、アマチュアでも普通に使えば良いと思います。
ただし、MFCはライブラリ(フレームワーク)自体に癖があるので、それを勉強するのにまた一苦労する必要がありますが。

>将来的にはWTLを利用したいのですが、WikiにはWTLはAPIと書いてありますが
>C++用テンプレートなのでしょうか(初歩的な質問かも知れませんがC++はほとんど分からないので)

C++のテンプレートという機能を用いて書かれたライブラリです。
なのでC++でしか利用できません。

C++が使えるであれば、MFCやWTL以外にも色々ライブラリがあるのですが、使えるのがC言語だけとなるとAPIを直接叩くしか無いかなぁと思います。

参考URL:http://next1.cc.it-hiroshima.ac.jp/CPPPUBLISH/node14.html

有料=プロが使う物、ではないと思います。
・MFCはC++用のライブラリなので、C言語しかできないのであれば使えない。
・そもそもVisualStudioの有料版を持っていないとMFCが入っていないから使えない。
という事実があるだけかと。
なので、それなりの規模のプログラムを書くつもりであるのなら、MFCを使ったほうが保守性が高まる(はずな)ので、アマチュアでも普通に使えば良いと思います。
ただし、MFCはライブラリ(フレームワーク)自体に癖があるので、それを勉強するのにまた一苦労する必要がありますが。

...続きを読む

QMFCなのかWin32APIなのか

みなさんはじめまして。グフです。
これからWindows上でC/C++(VisualStudio.NET2003)
にて、Windowsアプリケーション開発の勉強を始め
ようとしています。

いろんなサイトや書籍を見ている中で、Windowsアプリ
の開発方法としてMFCをつかうやり方と、Win32APIで
開発する方法の2つがあることがわかりました。

これからWindowsの勉強を行うにはどちらの方法で開発
するのが望ましいのでしょうか?
ケース by ケースだとは思いますが、何かアドバイス
いただければと思いまして、投稿させていただきました。

やはり基礎からおさえるのであれば、Win32APIの方が
よろしいのでしょうか?

今後のWinFX環境を考えると、Win32APIでの知識が無駄
になってしまうということはないのでしょうか?

Aベストアンサー

>ゲームはやはりWin32APIとDirectXで作られているパターンが多いのでしょうか?
はい。例えばDirectX9にくるC++のサンプルは9割がSDKで作られています。
MFCで作る場合のサンプルもありますが、ゲームを作る場合
MFCの恩恵はほとんどないので、SDKがメインです。

>業務アプリケーションへの適用も考えています。
MFCと同じ機能をSDKからつくろうとするとむちゃくちゃ大変です。
(例えば印刷プレビューとか)
業務アプリの場合イレギュラーなことをしない限りMFCで作ることが多いかもしれません。
ただやはりSDKを理解したうえでMFCを使うべきだと思います。



SDKの解説サイトで一番有名なサイトです。
「猫でもわかるプログラミング」
http://www.kumei.ne.jp/c_lang/

書籍なら
山本信雄著 VisualC++(1)はじめてのWindowsプログラミング
がお勧め。
http://esbooks.yahoo.co.jp/books/detail?accd=30630203

参考URL:http://www.kumei.ne.jp/c_lang/,http://esbooks.yahoo.co.jp/books/detail?accd=30630203

>ゲームはやはりWin32APIとDirectXで作られているパターンが多いのでしょうか?
はい。例えばDirectX9にくるC++のサンプルは9割がSDKで作られています。
MFCで作る場合のサンプルもありますが、ゲームを作る場合
MFCの恩恵はほとんどないので、SDKがメインです。

>業務アプリケーションへの適用も考えています。
MFCと同じ機能をSDKからつくろうとするとむちゃくちゃ大変です。
(例えば印刷プレビューとか)
業務アプリの場合イレギュラーなことをしない限りMFCで作ることが多いかもしれません。
ただや...続きを読む


人気Q&Aランキング

おすすめ情報