986コメント350KB

COM の世界を斬る！

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

0001IUnknown

NGNG

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

0507497

NGNG

互換性に関しては
__uuidof( Excel::Application )
のところがポイントですかね。
Excel97で持っているUUIDを渡すべきかな?

場つなぎ的なサンプルしかないのでこれも試行錯誤するしかないですね。

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

NGNG

バージョンなしのProgIDを使えばいい。
が、97～2002で全く挙動が一緒だという保証はないと思うが。

0509497

NGNG

"Excel.Application.9" みたいなのがバージョン付きで
"Excel.Application" みたいなのがバージョンなしのProgIDなんでしょうか。

やりたいことはセルの値の取得と設定、マクロの起動くらいなので
バージョンには依存しないと思われます。

最新のOLD+バージョン無しProgIDの線で攻めてみます。

0510499

NGNG

>>507
調べまくってわかりました。
EXCEL95がxl5jp32.olb、
EXCEL97がEXCEL8.olb、
ELECEL2000がEXCEL9.olbなんですね。
それで折れが調べた限り
xl5jp32.olbとEXCEL9.olbは
コーポネント上の互換性は無いみたいです。
インターフェイスやそのメソッドとかは
なんとなく似てるんですが。
自分のWin2000ではxl5jp32.olbのインターフェイスを呼ぶと
何故か失敗するので確かめることはできなかったんですけど。
EXCEL8.olbは手元に無いのでわかりませんでした。

0511497

NGNG

こりゃああきらめてVBを間に挟むしかないかな。

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

NGNG

↑みたいなのを#importを介さずに同じ事するにはどうすんだべ？
BCCからも使いたいっぺ。

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

NGNG

>>512
当然だが、C++からは直でタイプライブラリは読めないので
C++のソースファイルへの変換が必要。
#importディレクティブは、OLBファイルから
TLHとTHIというC++のヘッダとソースを作り出す。
それに加え、OLBファイルからツールを使ってIDLファイルを作成し、
IDLファイルからMIDLコンパイラを使ってC++ヘッダをコンパイルする方法もある。
上記二つのどっちかのC++ソースを、何らかの方法でゲットしてBCCで使えるかどうか
試す。
又は、COMの機能を使って動的にタイプライブラリを読み出す事も可能。
LoadTypeLibEx()でITypeLibインターフェイスを取得する方法。

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

NGNG

一番古いバージョンのExcelのタイプライブラリをインポートして、
CLSIDFromProgID( "Excel.Application" )ではだめでしょうか？

だめなら、全てIDispatch経由でアクセスするしかないでしょうか...

0515499

NGNG

>>514
497？
ならすいません。ウソこいてました。
EXCEL9.olbはxl5jp32.olbの上位互換性を持ってるようです。
xl5jp32.olbで公開されているインターフェイスは
dispinterfaceだけしかありません。
EXCEL9.olbはそれに加えdual interfaceとinterfaceを公開しているようです。
しかし、xl5jp32.olbで公開されている
dispinterface _Globalとdispinterface Applicationの
このふたつは何故かEXCEL9.olbには無いです。それ以外の
dispinterfaceは定義されているようです。
自分はEXCELにはあまり詳しくないんで
わからないんですが無くてもいいんですかね？
まあ結論としては、インポートするOLDはEXCEL9.olbで1つでOK。
ただし、xl5jp32.olbへのアクセスはIDispatch経由以外ないと、
こうなると思います。

0516499

NGNG

＞ただし、xl5jp32.olbへのアクセスはIDispatch経由以外ないと、
＞こうなると思います。
xl5jp32.olbと互換性を持たせるなら、IDispatch経由以外ないと
の間違いです。

0517514

NGNG

>>515 497ではないですが(^^;)

古いexcel等は確かおっしゃるとおりdispinterfaceしか定義されていなかった
と記憶しています。

そこで >>497 さんは #import を使っているみたいですから、#import すれば
Dispatch経由でアクセスしてくれるラッパが自動的にできないかなーと思ったしだいです。

今手元に環境が無いのでおぼろげな記憶だけですが..

だめならやっぱり >>514 に書いたとおり、
せめて excel のクラスIDぐらいはバージョン非依存で取得して、
あとは自分で IDispatch 経由でアクセスするしかないかと..

0518497

NGNG

>>514-517
ありがとーございましし。

>xl5jp32.olbと互換性を持たせるなら、IDispatch経由以外ないと

コードレベルでの互換をとるなら、という意味ととってよいでしょうか。
OLBは今ある最新のものを使うとして、それがofficeのバージョンに
依存するかどうか、が一番の焦点だったのですが、問題なさそうですね。

とりあえず、バージョン非互換のクラスID+OLBのインポートで
テストしてみます。
2chで初めて人に感謝しました。

0519sage

NGNG

すんません質問です。DelphiでCOMを作る方法を探しています。

Delphi6 PersonalでCOMが作れるか調べていたのですが、
Personalにはウィザードがないようです。ベタに作る手は
あると思うのですが、Googleでもあまり情報がなく。

VC++は歯が立たないので、ほかの言語でCOM作って遊ぼうと
している次第で。WSC、VB6、.Net(C#)は実践済み。

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

NGNG

それだけできてVC++で作れないというのが信じられない

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

NGNG

hello worldだけとか？<実践済み

WSC(わんだーすわんからー？)/C# がCOMと関係あるとは思えない

0522519

NGNG

sage間違いすいません。

>>520
Cの経験がないのです。ニセモノです私（恥）

>>521
ASP/スクリプト環境で使うことを考えていたのです。
作ったものが呼べるとわかればあとは何とかなると思っています。

WSCはWindows Script Componentです。あまり流行ってませんが。
スクリプトのかたまりをCOMとして呼べる代物。
C#/.netはinterop経由でアセンブリをCOMとして呼べます。

VBならActiveX DLLでCOMのこと何も知らずに作れるので、
気楽なものかと思っていたのですが。このスレ読む限り
非常にレベル高そうですね。

ここまで書いてCOMの意味を誤解している気がしてきました。

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

NGNG

生COMの実装はカナーリつらいぞ。
知識として知っておくのはいいかもしれんが、自分でやることはないだろうなあ。
DelphiでのやりかたはDelphi関連のスレで聞いた方がいいとおもう。
なんらかのサポートがあったと思うがよく知らない。

0524519

NGNG

ありがとうございます。場所を変えて聞いてみます。

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

NGNG

今からCOMはかなりお勧めしない。
やるならオートメーションは意図的に省いて
それ以外のアーキテキチャを勉強を勉強すべき。
マーシャリングとかそこらへん。
俺は確信に至った。
IDispatchやIDispatchExなんてのは
明らかに死に行く技術だ。存在価値ゼロ。

0526ななし

NGNG

>>525

そこまで読み切れる判断力がうらやましい。（決して皮肉とかじゃないですよ）
VBがやっとな俺の頭脳では、高度な技術の是非までは残念ながら判定できない。(泣

0527sage

NGNG

497です。
なんとかうまいことC++からExcelを操作することができるようになりましし。

重ね重ねお礼を申し上げます。

0528ななし

NGNG

age

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

NGNG

>それ以外のアーキテキチャを勉強を勉強すべき。
君はまず日本語を勉強すべき。

0530ななし

NGNG

>>525
>>529
単に手が滑ったか、コピペミス程度のことと思われ。

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

NGNG

アーキテキチャ

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

NGNG

>Excelを操作することができるようになりましし
こういうのってIDispatchのおかげじゃないの？

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

NGNG

このスレでMFCアプリケーションからのMSHTMLの利用方法に関する質問をしてもいいですか？
Web制作板はscriptの話ばっかりで参考にならなくて。

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

NGNG

>>533
こんなスレもあるよ。
http://pc.2ch.net/test/read.cgi/tech/982930049/l50

0535533

NGNG

>>534 おおう。サンクス。とりあえずそっち全部読んでみるよ。それでもわからんかったら帰ってくるかも。

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

NGNG

age

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

NGNG

COMってEJBとかと比較されますけど、速度はどうなんでしょうか？単純に比較は
しにくいかもしれないですけどVBとVCで作ったCOMの比較とEJBを比較するとどの
程度の速度差になるのでしょうか？やはりATLなどでVCのCOMがあまりはやらない
のはVBなどでも満足いく速度だから？

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

NGNG

>>537
>VBとVCで作ったCOMの比較とEJBを比較するとどの程度の速度差になるのでしょうか？
何の速度差か知らないけど多分、
VC>>>>>VB=>EJB
でしょう。

>やはりATLなどでVCのCOMがあまりはやらないのはVBなどでも満足いく速度だから？

なにが「やはり」なのかはおいといて、
エンドユーザー／開発者から見た場合、COMはVBの為に作られたんだから、
そもそもVCで流行るはずが無いのは当然の結果かと。
VCだけで使うんなら、ただのDLLでもなんでもいいし。
VCでのCOMは「作る」よりも「しかたなく使う」が圧倒的。
速度については、VBは元々遅いから、それで満足する様なやつらからは
文句はでないってだけだと思う。速いマシンに換えるとかね。
それで満足しないやつらは他の手段を模索するでしょう。

0539COMビギナ

NGNG

どうかご教授を。

タイプライブラリにenumで定義した定数シンボルを、
XMLで記述されたクライアントから参照することは可能でしょうか？

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

0540COMビギナ

NGNG

連続カキコでスマソ。

ちょっと誤解を招きそうな表現なので書き直します。

enum定義を含むタイプライブラリを、XMLで利用する際に、
その定義されたシンボルを参照することは可能でしょうか？

よろしくです。

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

NGNG

無理

0542COMビギナ

NGNG

>>541

レスどもです。
やっぱ無理ですか。
別な方法を考えます。

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

NGNG

COMってコールバック関数を引数に出来ないんだねぇ。
クライアントにコネクションポイント実装させるのもなあ。
しかし本気でこの型制限にはいらつくよ。何も出来やしねえじゃねえか。

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

NGNG

素直にインターフェイスポインタ渡せよ。

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

NGNG

まったくだ。コールバック関数よりはるかに柔軟だと思うが。

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

NGNG

COMにおける配列参照はいままでも話題になっては
いるのですが、私も文字列の配列をCOM<->VC++クラ
イアント間でやり取りする方法に悩んでいます。

どなたか以下の状況で実装されているソースをご存知
ありませんか？

(1)VC++クライアント側に配列のインスタンスがある。
これはCOleSafeArray

(2)配列はBSTRの一次元構造

(3)COM側で、受け取った配列の参照に対して操作を加える

よろしくお願いします。

0547543

NGNG

>>544-545
ピュアなCやC++の環境で使いたい場合どうすんの？
それだとCOMクライアント専用になっちゃうじゃん。
あと質問。
IDLでメンバのオーバーロードを定義すると怒るんだけど。
これって仕様？
だとしたら本当に糞だなCOMって。

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

NGNG

古い話してるね～
ＣＯＭなんてもうないだろ。
今はＥＸＥだよ。

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

NGNG

コールバックされたいクラスの事だよな。
それなら、別にIUnknownから継承をうけて、実装を
いれたとしても、pureなC++でも使えると思うが。

0550名前：デフォルトの名無しさん

NGNG

>>548
意味不明。ネタにしても自殺を勧めたくなるほどつまらん。

0551543

NGNG

>>549
IUnknownから継承を受けるには
IUnknownの実装を入れなければならないと思うけど。
Release()とかダミーで実装させるの？

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

NGNG

真っ当に実装したらいいやん。

0553543

NGNG

>>552
それじゃ、COMで実装させることと変わりないじゃん。(笑
MSだって、DirectXとかの例があるし諦めろってことだな。
所詮過渡期の技術か。

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ファイルなどでなんとか
ならないものかと思いました。

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