986コメント350KB

COM の世界を斬る！

■ このスレッドは過去ログ倉庫に格納されています

0001IUnknown

NGNG

ATL や MFC でラッピングされていない素顔の COM について語り合いましょう。

0554デフォルトの名無しさん

NGNG

＞553
でも、COMクライアント専用(この語もなんだか意味不明っぽいが)
というわけではないだろ。

0555デフォルトの名無しさん

NGNG

Cからタイプライブラリってどうやって使うんですか？
FreeのBCCでExcelの定数を認識させたいんですが、
さっぱりです。Invokeとかはなんとなくつくれるんですが。
Excelのタイプライブラリの参照例みたいなコードどこかに無いでしょうか

0556デフォルトの名無しさん

NGNG

>>553
お前、結局何が不服なんだ？
まぁ過渡期ってのは間違いないだろうな。といってもあるものすべて過渡期と言えるが。
安心しろ。いろんな欠点は.NETで解消されてるだろうから。

0557543

NGNG

>>556
俺は、CやC++用のライブラリをCOMで作りたい。
COMの基本的な概念、インターフェイスとか参照カウントなどは
良いと思うのでそれは導入したい。
しかし、マーシャリングやオートメション、スプリクト言語対応
といった機能は別に使わないのでいらない。
だから、そういったものに付随する制限まで課せられるのは
イヤだなと。
それに、C++で使う為のライブラリをC++で作ってるのに、
訳のわからない理由でC++の機能が使えなくなるのは
なんだか納得がいかない。
だったら使うなと言わないで欲しい。
代わりになるものがあるなら別だが。
生のC++や.NETでは代わりにはならない。

0558デフォルトの名無しさん

NGNG

>>543
MS社某のお言葉。
0.1%の比率に過ぎないないコンポーネントビルダーは、
99.9%のVBプログラマ向けに、彼らの頭脳では製造不可能な
ものを構築するために存在するんだそうだ。
COMのさまざまな制限はVBあるいはVBA/VBSとの接点による
ものであり、核心部分はC++で記述、フロントをVB/ASP等で
安く作らせるための構図であると。

0559ななし

NGNG

>>558

ホンネなんだろうけど・・・正直過ぎ。(苦笑)

0560デフォルトの名無しさん

NGNG

あの構成を見てそう思わない奴は居ないと思う。
いまさら言ってるお前って・・・

0561543

NGNG

>>543
いや、COM初心者の俺に説明してくれただけだよ。
いや、よくわかりました。
もう愚痴を言うのはやめるよ。

0562デフォルトの名無しさん

NGNG

スレッディングモデル絡みの質問なんですが、
ActiveIMM(ActiveX)のCOMサーバをCoIntilaizeEx(NULL,COINIT_MULTITHREADED)で初期化した
スレッド(MTA)で使おうとすると[REGDB_E_IIDNOTREG]なるエラーが出てインターフェイスが
取得できません。
レジストリでそのCLSIDを見ると[ThreadingModel]は[Apartment]でした。
MSのサポート技術情報を見る限りMTA所属のスレッドでも、[Apartment]で登録されている
COMサーバはプロキシ経由で使えそうなのですが、なにか必要な手続きがあるのでしょうか？

ちなみにCoIntilaize()(STA)で初期化したときは正常に取得できます。

0563デフォルトの名無しさん

NGNG

IMarshalに答えない仕組みなんじゃない。あるいは、local属性つけてるか。

0564デフォルトの名無しさん

NGNG

>>558
ガーン、おれは残り99.9%の中のその他大勢だったのか・・・
0.1%の中にはいるにはどうすればいいんだ・・・(鬱

0565デフォルトの名無しさん

NGNG

>>564
0.1%なんて世紀末におけるサウザーぐらいな奴と思われ。
フハハハーとか言って、余興でジジイ殺しちゃうような。

0566デフォルトの名無しさん

NGNG

開発言語の格差をＣＯＭで吸収しようという。
ただしオブジェクトはバイナリレベルで提供と。

0567ななし

NGNG

age

0568デフォルトの名無しさん

NGNG

マーシャリングの質問。
メインSTAで作成したインターフェイスポインタを別のMTAなスレッドで
マーシャリングせずに使ったら、普通に使えてしまったんだがこれって
このまま使っても問題でないんだろうか？
その逆で、MTAなスレッドで取得したインターフェイスポインタをメインSTAで
使用しても同じように問題なく使えました。

ちなみにマーシャリングしようとするとエラーが出て、マーシャリングが
できないんで、そのまま使ってみたんだけど…。

う～ん、COMは良く分からん（；´д⊂

0569デフォルトの名無しさん

NGNG

C++のセマンティクでは使えて当然。STA側のオブジェクトがクリティカルセクションの
保護してなくて、かつ同時に複数のMTAからさわるなら、やめといたが無難。
MTAの生ポインタをSTAが使うのは、別に構わない。

0570デフォルトの名無しさん

NGNG

>>568
インターフェイスポインタをどうやって渡したのかによるね。
インターフェイスのメソッドパラメータで渡してるなら、COMが勝手に
マーシャリングしてくれるから問題なし。問題なのはグローバル変数とかで
共有している場合だけ。

0571568

NGNG

レスありがとう。

>>569
「アパートメント境界を越えての使用はマーシャリングする必要がある」
って各所に書かれてるんだけど、それは気にしなくてもいいの？
普通のコードと同じ扱いで、そのコードがスレッドセーフ(ThreadingModel=both)なら
そのまま使えて、そうでなければ(ThreadingModel=Apartment)クリティカルセクション
とかで保護すればいいだけ？

>>570
グローバル変数で共有してます…。

そもそも、何故マーシャリングできないのかが不明なんですよね。
マーシャリングするには[HKEY_CLASSES_ROOT\Interface]あたりのレジストリ
に何か登録されてないと駄目とかあります？

0572デフォルトの名無しさん

NGNG

>>571
それならマーシャリングが必要。マーシャリングするには、マーシャリング用のコードが必要。
TLBがあるならユニバーサルマーシャラを使う。IDLがあるならMIDLでマーシャリングコードを作れる。

ちなみに、CriticalSectionを使うとかいう問題ではないのでご注意。

0573568

NGNG

>>571
ってことは、マーシャリングできないのはマーシャリングコードが無いからか。
ちなみに元発言のMTAなCOMコンポーネントはDirectPlayなんでtlbもidlもないです。
STAの方はidlならあったんだけど、こっちもMS提供な代物なのでいじってもしょうがないしな。
idlがあるからそれを継承してマーシャリング機能だけ追加したものを作るってのは可能？

一番手っ取り早い解決方法は、パフォーマンスを犠牲にして全スレッドをSTAで
やればいいんだろうけど、なんか悔しいし…。

＞ちなみに、CriticalSectionを使うとかいう問題ではないのでご注意。
アパートメント境界を越えたアクセスは何かしらの方法でマーシャリングは必須。
ただ、マーシャリングした結果が生ポインタの場合もある。
と言う認識でいいのかな？

0574デフォルトの名無しさん

NGNG

>>573
That's correct.

0575569

NGNG

なんか、盛り上がってるが……。STA用のコンポーネントの代表はOCX.こいつは、HWNDを
使ったりする。当然、作成したスレッドで動く必要がある。マーシャリングすると、
Windowsメッセージ経由でリクエストされるから、DefWndProcからの呼び出しとなる
ってことは、そのSTAで動くから問題なし。だから、569はちょっと乱暴で、572が正しい。
でも、ユーティリティクラス（引数同志の演算とか。ハッシュ計算するとかさ）をVBで作っちゃった
ような場合（だからSTA)で、TLS使ってないことがわかりきってれば、別にマーシャリング
しなくたって構わないわけ（だが、透過性を無視してる＝COMの原理破壊）。
その他、MTAでCoCreateInstanceするとブルブルとか、いろいろあって、おもしろい。

0576569

NGNG

>>573
あと、STAだからパフォーマンス犠牲というのは必ずしも正しくはない。並行動作
に意味がないのであれば、STAはひたすら同一スレッドのスタックを使いながら
突っ走るから、実は高速な動作が1番期待可能。（アウトプロセスサーバがSTAだと
リクエスト1個づつしか処理できないから、パフォーマンスは低くなるけど）

0577568

NGNG

また、レスありがとう。
まず訂正。前発言の>>571は>>572でした…。

>>573
全部「That's correct.」と解釈してもいいんだろうか…。
説明が無いだけにちょっと不安(^^;

>>569さん
COMの手順に則る限りはマーシャリングは必要なんですね。
「そうでなければ自己責任で…」って感じでしょうか。(^^;
もう一つのパフォーマンス犠牲の話ですが、今回はDiretPlay使っているので
たぶんパフォーマンス落ちます。測っては無いので、どれぐらい落ちるかは不明ですが。
それに、DirectPlayがスレッドを乱立してる感じなんで並行動作してるでしょうし。

う～ん、どうにも解決手段が見つからない。こう言う時こそMSDNのインシデント使うべきか…。

0578568

NGNG

ごめん、また間違えてる。>>573は>>574です…。

0579569

NGNG

DirectPlay使ったことないから、わかんないなぁ（使ってる人、尊敬する）。
STA側ってなに？バイナリの内側の処理を勘案してMTAから使っても平気とか考えるって
のがCOM違反なだけで、使って問題なければ別にOKなわけだから、そっちでごまかすって
手もあるよね。
STAをMTA（のランダムなスレッド）から生アクセスする問題は、次の点
1.レースコンディション（そりゃそうでしょ？）
2.HWNDの取り扱い（これ違うスレッドから呼ぶとエラー食らうWin32APIもあるから当然）
3.規約違反（気にすればってことで）
4.TLS（スレッドローカルストレージ）使われてるとクラッシュ
#1.については、STAで作ってるんだからクリティカルセクション保護は当然してない。
これらに問題なければ3.に抵触するってだけの話。

0580569

NGNG

5.中で上の1,2,4を持ったSTAのオブジェクトを作って使っている場合もまずい
ということもあるから、基本はマーシャリング必須。しかし、5.についても実は
雰囲気でわかったりもするし（そもそもデバッガで動かせばロードしたDLLがわかる
から、把握できるし。

0581568

NGNG

>>569さん
STAなコンポーネントはActiveIMMっていうGlobalIMEを使うのに必要な
ActiveXコンポーネントです。

で、
＞STAをMTA（のランダムなスレッド）から生アクセス
してみたんだけど、駄目でした。クラッシュはしなかったけど、どうにも
メッセージ処理が上手く言ってないっぽい。
[OnDefWindowProc()]←こんなメソッドもあるんでかなり怪しいし。
あと、クラッシュはしなかったんでTLSは使ってなさそう。ってな感じかな。
こっちはもうちょっと探ってみるけど…。

という事で、解決策は
・STA一本で行く
・何とか完全分離してみる
・マーシャリングコードを自分で用意してみる（できるのか？）
・MSDNのサポートで聞いてみる（「できません」と答えてきそう…）
・その他、あれば募集中ｗ
ってな所？

0582569

NGNG

では、自力マーシャリングでいくのがいいかな？ MTAからSTAへのマーシャリングの
問題点は、SendMessageしてSTAで処理が完了するまで待たされることにあるから、
STAで動いてる側に対してPostMessageで処理を行えと通知する。（ようするに、自分で
非同期COM呼び出しをするってこと）そもそも、STA側のインターフェイスポインタを
マーシャリングできないわけだから、いずれにしても自分でやるしかないし。
つまり、ActiveMMを貼り付け？てるウィンドウのHWNDをグローバルに可視状態にして、
MTAはそこめがけてPostMessage（WM_APP、wParam, lParam）してやるわけ。
応答が必要な場合は、Eventで待つか、グローバル変数に状態を入れてポールするしか
ないけど（SendMessageで応答を待つのも悪くはないが）。
注意点は、wParamやlParamに自動変数のポインタを渡すのは禁物って（あたりまえだけど）
ことぐらい。

0583569

NGNG

もしかしたらダブルかも知れないが……
上のは中途半端だからもう少し付け加えると、COMにマーシャリングさせられないわけだから、
STA側のウィンドウハンドラで、WM_APPを受け取ったら、wParamとかから、ActiveMMの適切
なメソッドを呼び出してやる（＝自分でプロクシ／スタブをやってやる）という意味です。

0584568

NGNG

>>569さん
いろいろとありがとう。ちと忙しくなってきたのですぐには試せないけど
とりあえず、手動マーシャリングの方向で作ってみます。

0585デフォルトの名無しさん

NGNG

なんだか難しいこと書いてるけど、CoMarshalInterfaceでダメな理由がなにかあるのか？

0586568

NGNG

>>585
DirectPlayにもActiveIMMにもマーシャリングコードが用意されてないらしいのですよ。
なんで、CoMarshalInterface()を使ってもマーシャリングできないのです。
それで、>>581の解決策のうち手動マーシャリングという話になったのですよ。

まぁ実際使ってるのは
CoMarshalInterThreadInterfaceInStream()
↑こっちですけど、中身は一緒ですし。
ちなみに返ってくるエラーはREGDB_E_IIDNOTREG(0x80040155L)です。
このエラーはMSDNに具体的な内容が記述されていないので、
「マーシャリングコードがないからマーシャリングできないらしい」
と言う不確かな結論になっているのですよ。

0587569

NGNG

ちなみに、pActiveIMM->QueryInterface(IID_IMarshal, (void**)&nannka);
して、HRESULT確かめてみるってのが、最初にすべきことだったかも。
ところで、ActiveIMMってのはどこの製品？なぜ、typelibマーシャリングを禁止
してるんだろ？ (MFCのDLLで作ったのかな？)

0588568

NGNG

見返すと>>586って「ですよ」だらけで変な言葉遣いだな(^^;

>>569さん
QueryInterface()やってみました。結果はE_NOINTERFACE(0x8004002)。
idlではIUnknownを継承してたのでやっぱりと言う感じ…。
それと、idlに「tlbは全く使用しません」ってなことも書いてありました。

ちなみにActiveIMMはMSの製品（のはず）で、Win9x系での多言語入力をサポートする
ActiveXコンポーネント。所定のSDK入れればWin2kでもコンパイルだけなら出来ます。

う～む、これ作った人がIUnknownから継承させたのが全ての元凶？(-_-;

0589569

NGNG

COMの場合、直接のC++の派生とQIは無関係だからそれは余り関係ないです。
たとえば、適当なOCXあたりに、QI(IID_IDispatch), QI(IID_ITypeInfo, QI(IID_IStream)
とか、やってけば、そこそこヒットします。
HRESULT QI(IID& iid, void** pp)
{
　if (IsEqualIID(iid, IID_IUnknwon) { *pp = this; return S_OK; }
　if (IsEqualIID(iid, IID_IStream) { *pp = m_stm; return S_OK; }
....
みたく実装するから。ミソは上のm_stmはQIに対して自分のthisではなく、こっちのthisを
返すこと。ワケワカな書き方だけど、まあそんな感じ。

0590569

NGNG

今、dimm.idlを見たけど、オートメーションコンパチ型で作られてないから、TypeLibマーシャラは利用できない。
で、見るからに、MessagePumpどうしたとか、スレッドべったりだから、これはすっぱりMTAからの利用は
あきらめて、ホストしているSTAに対してメッセージ投げてSTAで処理させるしかないっす。582の方法。

0591568

NGNG

>>569さん
ふむふむ、要はCOMサーバ内に目的のインターフェイスが実装されてて
それをQIで返してくれれば、継承しようがしまいが問題ないと言うことですね。
もちろん、IUnknownは必須でしょうけど。
で、やっぱり手動マーシャリングしかないのですね。うむ、それで頑張ろう。

いろいろ聞いたついでにもう一つ聞いておきたいんですが、STA側からMTA側の
インターフェイスをグローバルで共有して扱う場合は、規約違反とパフォーマンス
ペナルティがあるだけで特に問題ない？
実際にコードを走らせた時は問題なく動いてるけど、どうなんでしょう？

0592569

NGNG

STAからMTA使うのって、全然問題なしと思ってるけど。そもそもMTAってのは、特定の
スレッドに結びつかないってことなんだから。じゃあなぜ、BothとFreeに分かれてるか
といえば、STAでCoCreateInstanceしたときに、どこに作られるかって点がひとつ。
(Bothは呼び出したSTAに作られるけどFreeは「どこか」に作られる）
ちなみに、Inside COM日本語版309ページに「つまり、フリースレッドのコンポーネント
は、同じプロセス内のアパートメントスレッドに対してポインタを直接渡せるのである」
って書ききってるよ、今、初めてそのへん読んだけど。いや、実はなぜ、STA->MTAに
マーシャリングが必要かそっちがわからん……

0593569

NGNG

あと、その場合、パフォーマンスペナルティは無いよ。同時に2つのSTAからMTAの
オブジェクトを（デュアルCPUで）使うとしたって、MTAでレースコンディションに
対するクリティカルセクションでひっかかるとかはあるにしても、両方のSTAは、
単にcallで自分のとこのスタックを走ってくだけだから。（生ポインタだから、プロクシ
を通さない、つまりC++での関数呼び出しと変わらないわけ）

0594568

NGNG

>>569さん
ん？BothはSTAでもMTAでもどっちでも利用可能ってことじゃないんですか？
実際は作成したスレッドが所属する方に入って、STAならCOMの機構により順番に
処理されてMTAならリアルタイムに処理される。
そこで、普通にスレッドセーフに作ればBothでいけるんだけど、STAに使われる
メッセージポンプを壊すような作りにしてるとか、STAで使うのがまずい場合だけ
Freeになると
http://support.microsoft.com/default.aspx?scid=%2Fisapi%2Fgomscom%2Easp%3Ftarget%3D%2Fjapan%2Fsupport%2Fkb%2Farticles%2Fjp150%2F7%2F77%2Easp&LN=JA#
↑ここらへん読んでそう思ってました。

STAからMTAなインターフェイスを使う時にマーシャリングする理由は
カスタムマーシャリングを考慮してるからじゃないんでしょうか？
普通は必要ないけれども、カスタムマーシャリングをする時としない時とを
場合わけするとややこしいから、とりあえずしとけ。みたいな

0595569

NGNG

>カスタムマーシャリングを考慮してるからじゃないんでしょうか
あっ、そうか。それはすごく納得。
>メッセージポンプを壊すような作りにしてるとか
確かに引用ページにもそう書いてあるけど、これは意味不明。
でも、その後にある、STAクライアントが自分のインターフェイスポインタをコールバック
用に渡すシナリオについては、確かにマーシャリングが必要だから、生ポインタを使う
呼び出しがまずいってのもわかった。
thanks.

0596デフォルトの名無しさん

NGNG

あげ

0597デフォルトの名無しさん

NGNG

しつもーん

COleClientItem* pItem = new COleClientItem( pDocument );
pItem->CreateFromFile("TEST.XLS");

上記の方法で作成されたOLEアイテムから TEST.XLS を抽出して
保存する方法が分かりません、どうやればいいのでしょうか？

0598デフォルトの名無しさん

NGNG

ちょいとはずすかもしれんが
COM公開後は仕様変更しちゃだめ
機能追加は実装の追加で補い旧実装はそのまま放置
COMには「バージョン管理はしない」などという
お約束事があったかと思うが
皆様はお考えを頂戴したく仕る

0599デフォルトの名無しさん

NGNG

実装を放置しなくてリプレースしても構わないと思うが。
DirectX3位の時、バージョン上げたら実行結果が異なることがあったと思う。
新バージョンは機能追加ではなく新しいインターフェイスで公開すればいい

0600デフォルトの名無しさん

NGNG

>>599
このCOMがインプロセスでもローカルサーバでもかまわないが
閉じた世界でのFixupであれば599の言うのも正論であると思う
がDCOMリモートに配置された分散オブジェクトで
たとえば第一次リリースしたDCOMを多数の
部門で共有していた場合などは勝手に仕様変えて動作が変わると
困るのでは?

COMを設計する上で
仕様上の規約なのかどうかをはっきりさせたいのですが

皆様のご意見をお願いします

0601デフォルトの名無しさん

NGNG

Interfaces are immutable. Once assigned an IID and published, no element of the interface definition may change.
超訳）インターフェイスはイミュータブルに決まってんだろ。IIDを割り当てて公開しちまったら、何ひとつたりとも変えんじゃねぇ。ゴルァ。

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_therules.asp

とは言ったって、使ってるのが自分だけとかだったら、思う存分変えても誰も困らないのもこれ自明。

0602デフォルトの名無しさん

NGNG

COMコンポーネントを初めて書きました。
配布用にDll(Un)RegisterServerを呼ぶ（アン）インストーラをわざわざ別プログラムで
用意したのですが、なんだか面倒です。
一般的にはどのような形態で配布されるのでしょうか？

0603デフォルトの名無しさん

NGNG

>>601
ご回答ありがとうございます
そうですよね確か
だから基本設計の時にじっくりと拡張したときの事まで
考えてつくらないと恥ずかしいものができてしまうとか
ありですよね
慎重に設計せねば・・(事故レス)

0604デフォルトの名無しさん

NGNG

>> 603
なぜ？
第1段階
interface IFoo : IDispatch { // まあdualインターフェイスでいいや。
HREUSLT method1();
};
coclass {
[default] interface IFoo;
};
第2段階
interface IFooEx : IFoo {
HRESULT methodEx();
}
coclass {
[default] interface IFooEx;
interface IFoo;
};
第3段階
interface IFooExEx : IFooEx {
HRESULT methodExEx();
}
coclass {
[default] interface IFooExEx;
interface IFooEx;
interface IFoo;
};
で、いいじゃん。＜よかねぇよ。でも、この手はありだから。

0605デフォルトの名無しさん

NGNG

>>604
ケースバイケースということで
基本的には method1()を公開したら
method1()の内部動作を修正するのは
はまずいです。内部動作仕様の変更は×です
methodEx... methodExExと新規メソッドとして
機能を追加するなら○です
ようは問題があった古いバージョンも残しておかなくては
ならないが正式なCOMの仕様だと思いますが・・
　・バージョン管理を行わない(バイナリレベルの互換性保障)
　　ちなみにidlで内部バージョンを定義はできますが

ソースは古山さんの「DCOMガイドブック」オーム社です
もちろん個人レベルのローカルPC内の仕様変更は誰にも
影響はでませんからありということで

0606デフォルトの名無しさん

NGNG

>>602
配布んときはselfregフラグ立てて(リソースのバージョン情報だったかな)
インストーラにレジストさせてるよ漏れは
そうでなければ客にレジストをやらせる方法もある(爆)
dll, exe, ocxでも対外はsystem32にぶっこむのパターンが多いと
思う　これもインストーラまかせ

0607602

NGNG

>>606
selfregというのは知りませんでした。
インストーラというのはやはり別プログラムですよね？
本当にただのdllひとつだけなので、例えばinfファイルなどでなんとか
ならないものかと思いました。

0608デフォルトの名無しさん

NGNG

>>607
Windowsインストーラでもやっくれると思うがな
あとはjacarta-tomcatのisaapiリダイレクトDLLのインストールで
するような　hoge.regファイルを自分で書いて
インストーラのスクリプトで自動実行させて登録させるとか
どっちにしてもテストの時は面倒で膨れ上がったレジストリサイズが
元にもどらないのは不満だけどね
仕様だからしょぅがない

0609デフォルトの名無しさん

NGNG

Wizardで作成するATL, ActiveX, などの多数のCOMタイプが不明
だと思いません?

どのCOMタイプがなにが得意なのかみなで整理しまへんか?

ちなみに今漏れの手元で動かしてるのはVC++7.0っす
VC++6.0の人も参加してください

プロジェクト作成時の大項目
(1)ATL Server Webサービス
(2)ATL Serverプロジェクト
(3)ATLプロジェクト

そのプロジェクトに追加する中項目
(a)ActiveXコントロールのMFCサポート
(b)ATL Active Server Pageコンポーネント
(c)ATL COM+1.0コンポーネント
(d)ATL OLEDBコンシュマー
(e)ATL OLEDBプロパイダ
(f)ATL Server Webサービス
(g)ATL コントロール
(h)ATL　シンプルオブジェクト
(i)ATL ダイアログ
(j)ATL パフォーマンスモニタ
(k)ATL プロパティページ
(l)MFC ODBCコンシューマ
(m)MFCにATLサポートを追加

ふぅ～

0610デフォルトの名無しさん

NGNG

自分で選べないんじゃ使うな

0611デフォルトの名無しさん

NGNG

>>607
rundll32.exeから呼び出せる関数をエクスポートして
それをinfファイルに記述するってのはどうよ？

0612デフォルトの名無しさん

NGNG

OLEを使ってDnDを実装しているのですが、
エクスプローラ相手にドロップしたところ、
ファイルの移動が開始するまで（圧縮ファイルを一時ファイルに展開している間）
エクスプローラが固まってしまいます。
これを回避したいのですが、、、

IAdviceSinkとやらで非同期の通信が出来るようですが、
Drag&Dropにも適応できるんですか？
IViewObjectが無いので出来ないような気もするのですが。

0613デフォルトの名無しさん

NGNG

>>612圧縮ファイルって何？
ドラッグ開始のタイミングで展開始めれば？

0614デフォルトの名無しさん

NGNG

COMってあんまししらないんですけど、
.NET出てきてCOMの価値が下がったってことありません？
今からでもCOM勉強したほうがいいですかね？

0615デフォルトの名無しさん

NGNG

自分で判断できないんじゃ使うな

0616デフォルトの名無しさん

NGNG

勉強しない方がいいだろ

0617デフォルトの名無しさん

NGNG

COMやる価値なし！

0618デフォルトの名無しさん

NGNG

知っておいてそんはないな。たとえレガシーだとしても。

0619デフォルトの名無しさん

NGNG

概念だけ知ってればよいってことかな

0620デフォルトの名無しさん

NGNG

概念？　実装が伴わない概念に意味がないと思うが？

0621デフォルトの名無しさん

NGNG

Borland イイ!

0622デフォルトの名無しさん

NGNG

えええ、三角形は実体がなくても概念として成立してますよお

0623デフォルトの名無しさん

NGNG

&heart

0624VB房

NGNG

質問です。

COMコンポーネントに実装されているメソッドがIDispatchインターフェイスなのか、
IUnknownインターフェイスなのか、確認する手段、ツール等はありますか？
(手元にソースがなく、バイナリしか存在しない前提で)

(例) ExcelのQuitメソッドが IDispatch/IUnknown のどちらなのか知りたい。

0625デフォルトの名無しさん

NGNG

OLE/COMオブジェクトビューアを使えば確認できるよ

VBはよく知らないけど、ObjectとしてアクセスするとIDispatch経由に
なるんじゃなかったっけ？

0626デフォルトの名無しさん

NGNG

>>625

> OLE/COMオブジェクトビューアを使えば確認できるよ

てことは、Visual Studio 6.0 の開発環境があればOKですね。

感謝！ m(_ _)m

0627デフォルトの名無しさん

NGNG

IDLもないなら、カスタムインターフェースで呼び出せるわけがないだろ。
IDLがあるなら、それみろ。

0628デフォルトの名無しさん

NGNG

>>627
IDLをコンパイルしたのがtypelibで、COMモジュールに同梱するのが通例。
OLE/COMビューアはそのビューアでもある。

IDispatchはtypelibを参照して名前でメソッドInvokeするためのインターフェース。
リフレクションみたいなそういう感じ・・・

0629628

NGNG

蛇足しちゃうとtypelibをメタデータと読み替えれば.NET。

0630VB房

NGNG

>>627-629
タイプライブラリは、単独のファイルなのでしょうか？それとも、
レジストリに記述されているもの？？
（よくわかってなくてスマソ）

0631デフォルトの名無しさん

NGNG

>>625
oleviewで見ても、そのとき何でアクセスしているかはわからんよ。
>>627
IDLは必須ではない。IDLのないCOM DLLはたくさんあるぞよ。
>>628
IDispatchにtypelibは必須ではありません。
>>629
ちょっと違いすぎますね。
>>630
単独のファイルにすることも、リソースとしてファイルに埋め込むこともできます。
レジストリには記述されません。レジストリに記述されるのはそのtypelibのIDだけ。

0632デフォルトの名無しさん

NGNG

>>624
参照設定をしないとコンパイルできない使い方がIUnknown
参照設定をしなくてもコンパイルできる使い方がIDispatch

0633デフォルトの名無しさん

NGNG

> oleviewで見ても、そのとき何でアクセスしているかはわからんよ。

あるインターフェースがIDispatch経由で呼び出せるかどうか、
は分るよ

0634デフォルトの名無しさん

NGNG

>>633
？インターフェイスは呼び出せませんが？メソッドのこと？
だったら「Quit」がIDispatchで呼び出せるかどうかは
やってみなけりゃわからない。oleview見たってわからない。

0635デフォルトの名無しさん

NGNG

>>634
は？
oleviewはIDispatch経由で取得できるインターフェースが列挙できるよ？

0636デフォルトの名無しさん

NGNG

>>635
うっそー！（爆笑）

そりゃ単にタイプライブラリの中身見てるだけだろ？
タイプライブラリに書いてあるからって呼び出せるとは限らんよ。

0637デフォルトの名無しさん

NGNG

>>635
？？？
少なくとも列挙できないと呼び出せないよ？

0638デフォルトの名無しさん

NGNG

>>637
636に対してだと思うが。。。

列挙って何を？GetIDsOfNamesが成功すりゃInvokeで呼び出せる。oleviewではそれができるかどうかは
わからん、って言ってるんだけど。
列挙ってGetIDsOfNamesのこと言ってるのかい？それが「やってみなけりゃわからない」ってことだよ。

0639デフォルトの名無しさん

NGNG

別スレで回答が得られなかったので専門スレで再度質問させていただきます。

普通、COMオブジェクト（ActiveXコントロールとか）をregsvr32でシステムに登録するときは
管理者権限で行いますが、Users権限でも使えるCOMオブジェクトというのはあるのでしょうか？
例えば、Usersグループのユーザがregsvr32を実行すると、もちろんシステムには登録できませんが
そのユーザの環境だけでは有効になる、というようなものはありえるのでしょうか？

それともCOMオブジェクトというものは必ず管理者権限でシステムに登録しないと
使えないものなのでしょうか？

よろしくおねがいします。

0640デフォルトの名無しさん

NGNG

アプリケーションというものはすべて管理者権限でインストールするものだ。
管理者以外が勝手にアプリケーションをインストールするから、ウィルスが
はびこったり、業務アプリが止まったりする。君が使っているPCはおそらく
君のものではあるまい。だったら君にはアプリケーションをインストールする
権限がないのだ。黙って管理者様の言うとおりにしなさい。

0641デフォルトの名無しさん

NGNG

>>640
いいえ自分のものです。
また、「アプリケーションというものはすべて管理者権限でインストールするものだ」という
理想論ではなく、>>639に関する答えをいただけると幸いです。

0642デフォルトの名無しさん

NGNG

世の中にはバカ管理者も多いけどな。

0643デフォルトの名無しさん

NGNG

2000以降ならHKEY_CURRENT_USER\Classesがあるし
side-by-side sharingもあるから
原理的には管理者権限がなくてもインストールできるはずだな
対応してるアプリは(MS製のものでさえ)見たことないけど

0644デフォルトの名無しさん

NGNG

>>641
理想論？？すべてのユーザーが勝手にアプリをインストールして、
それでもマシンが動き続けると思い込むほうがよっぽど理想論ですよ。
640が一番現実的なんです。

大体自分のものなのに管理者のパスワード知らないってどういうこと？
それがすでに意味不明なんだけど。

サイドバイサイドならMSのHPに情報があるけど、そういう問題ではないね。

0645デフォルトの名無しさん

NGNG

>>644
>それでもマシンが動き続けると思い込むほうがよっぽど理想論ですよ。
マシンが正常に動きつづけるなんて一言も言ってないよ。
「管理者以外でもインストールし得る」と考える方が現実的ってだけ。

>大体自分のものなのに管理者のパスワード知らないってどういうこと？
誰もパスワードがわからないなんて言ってないよ。
UsersでもCOMオブジェクトを有効にする環境がありえるのかと聞いてるだけ。

なんか勘違いしてるようだから、もう一回>>639を読み直したほうが良いと思う。

0646デフォルトの名無しさん

NGNG

>>645
>UsersでもCOMオブジェクトを有効にする環境がありえるのか
だからありえないといっているだろうが。

インストールするときにだけsu/RunAsするのは不満か？それとも知らないだけか。
パスワード知っているならそれができるだろうが。

管理者以外でもインストールしうるから現状に色々な問題があるんだろ。
マシンが正常に動き続けないんだったらインストールすることに何の
意味があるんだよ。勘違いは君だよ。もっと広い視野で物事考えないと
人間として成長できないぞ。

0647元質問者じゃないが

NGNG

>>646
>だからありえないといっているだろうが。

じゃあHKEY_CURRENT_USER\Classesはなんのためにあるんだよ。
「ありえない」んじゃなくて「仕組みはあるけど現状ではそういう運用を
する事が想定されてない」んだろ。

大体技術的に可能なのかどうかを聞いてるところで運用ポリシーの話
持ち出して来る事自体筋違い。

0648デフォルトの名無しさん

NGNG

>>646
>だからありえないといっているだろうが。
おいおい>>640以降そんなこと言ったの今回が初めてだろ。

あのさぁ、「実際にここに○○というActiveXコントロールがあってそれを管理者じゃないのに
インストールしたいけどどうすればいいですか？」なんて聞いてないの。
そういうことが可能かどうかって聞いてんの。

0649デフォルトの名無しさん

NGNG

Yes/Noで答える質問にはせめてYes/Noで答えれよ。
的外れな講釈たれる奴はたいがい無能。
政治家によくいるね。

0650デフォルトの名無しさん

NGNG

>>647-649
おまえら教えて君のくせにずいぶんとエラソーだな。（ｗ　身の程わきまえろ。
そんなに知りたきゃテメーで調べろよ。やってみればいいじゃないか。
やってみてそれが現実的かどうか考えてみなよ。ヒントはくれてやったろ。
UNIXな人にsuってどういうときに使うんですか？って聞いてみな。

＞じゃあHKEY_CURRENT_USER\Classesはなんのためにあるんだよ。
＞「ありえない」んじゃなくて「仕組みはあるけど現状ではそういう運用を
＞する事が想定されてない」んだろ。
その2つにどんな違いがあるのか教えてほしいもんだ。

＞あのさぁ、「実際にここに○○というActiveXコントロールがあってそれを管理者じゃないのに
＞インストールしたいけどどうすればいいですか？」なんて聞いてないの。
＞そういうことが可能かどうかって聞いてんの。
おいおい、その2つにもどういう違いがあるんだ？YesかNoかで答えろってなら、
すでに答えたとおりNoだ。YesであればHow？って質問なら答える必要はないな。Noだから。

少し行間読めよ。ボクイクチュ？

0651デフォルトの名無しさん

NGNG

HKEY_CURRENT_USER\Classesについての回答は無し、と。
やはり質問の主旨を理解できずに的外れな講釈をたれるDQN、と。

ま、こいつは根拠無しに「No」ってことしか言えないみたいだからもういいよ。
的外れな運用ポリシー論を主張したいなら別板逝きな。

0652デフォルトの名無しさん

NGNG

実際にやってみた。
１．まずテスト用の簡単なCOMオブジェクト（DLL）を作成。これを管理者権限でregsvr32。
２．Users権限からテスト用プログラムでDLLが使えることを確認。
３．HKEY_CLASSES_ROOTに登録されたキーをregeditでファイルに書き出す。（５ファイルできた）
４．テスト用DLLを管理者権限でregsvr32 /u。
５．Users権限からregeditでキーが削除されたことを確認。テスト用プログラムでもDLLが使用不可になっていることを確認。
６．先ほど書き出した５ファイルを編集。（HKEY_CLASSES_ROOTの部分をHKEY_CURRENT_USER\Software\Classesに置換）
７．Users権限でこの５ファイルをレジストリに結合。
８．Users権限からHKEY_CURRENT_USER\Software\Classesにキーが追加され、HKEY_CLASSES_ROOTにも同様に追加されていることを確認。
９．Users権限からテスト用プログラムでDLLが使えることを確認。

よって>>643が正解。
DQN>>640は板違いな講釈をたれた上に答えも間違い。

0653デフォルトの名無しさん

NGNG

>>640みたいな読解力のないDQNは早めに放置するのが得策。
いくら説明しても曲解しかしないから時間の無駄。

■ このスレッドは過去ログ倉庫に格納されています