COM の世界を斬る！
■ このスレッドは過去ログ倉庫に格納されています
0001IUnknown
NGNG0446デフォルトの名無しさん
NGNGとおもってUsersのユーザにしたけどだめでした。
そしてなぜかAdministratorsにしてもだめでした。
コンピュータの管理者(XPなので・・・)にしてみたらできました。
へんですね。コンピュータの管理者も所詮所属グループがAdministatorsになってる
だけなのに・・・
0447デフォルトの名無しさん
NGNG0448デフォルトの名無しさん
NGNGありゃ？できました。
IIS画面で停止->COM+のIIS？？？？をシャットダウン->IIS画面で起動
までやったんで大丈夫かと思ってたのに。
iisresetってさらに何かやってんですね。どうやら。
・・・けどやっぱりUsersだけだとだめでした。たぶん自分の見に行ってるレジストリの
権限が高いんですね。きっと。
0449デフォルトの名無しさん
NGNG組み込みたいのですが、うまい方法がわかりません。
Dllの仕組みの中にそういう機能ってありませんでしたっけ？
0450デフォルトの名無しさん
NGNG0451449
NGNGなにか期待と違う結果が・・・
C:\WINDOWS\System32\dllhost.exe
dllを呼び出した側のモジュール名が出てきました。？
0452デフォルトの名無しさん
NGNGDllMainで渡されるHINSTANCEを保存しておいて、それにGetModuleFileName()
0453449
NGNGありゃ？だめだ。というかdllhost.exeってただしいっちゃ正しいんだけどね。
dllhost.exeってCOM+だけの話かとおもってました。
GetDllFileNameとかあればよかったんだけど。
HINSTANCE g_hInstance;
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /*lpReserved*/)
{
g_hInstance = hInstance;
}
--
extern HINSTANCE g_hInstance;
hoge()
{
TCHAR fileName[_MAX_PATH];
::GetModuleFileName(g_hInstance, fileName, sizeof(fileName));
}
0454449
NGNG0455デフォルトの名無しさん
NGNG関係ないけど好きだった
0456デフォルトの名無しさん
NGNGエラー タイプ
(0x80004005)
エラーを特定できません
とは出るので、以下のように受けようとしても、Err.Numberは0のままなんです。
On Error Resume Next
MyCom.Hoge()
Response.Write("Error# " & Hex(Err.Number) & "<BR>")
Response.Write("Generated by: " & Err.Source & "<BR>")
Response.Write("Description: " & Err.Description & "<BR>")
On Errorじゃ受けられないんでしょうか？
0457デフォルトの名無しさん
NGNGしまった。受ける場所を間違え・・・
しかし今度はE_FAILしかかえってこんな・・・
0458デフォルトの名無しさん
NGNG多分ちゃんと登録されているオブジェクトのはずなのですが、
確かめる方法からわかりません。
0459デフォルトの名無しさん
NGNG何かがマズイ時
0460デフォルトの名無しさん
NGNG0461デフォルトの名無しさん
NGNGISupportErrorInfoとか調べてみてちょ
0462デフォルトの名無しさん
NGNG.NETからみたら過去の技術扱いでラッパーしかないですね。
0463デフォルトの名無しさん
NGNGIBindEventHandler インターフェースの
の、使い方(というか使われ方)を知ってる人いませんか？
解説書の書籍名でも結構です。情報をお待ちしております。
0464デフォルトの名無しさん
NGNG0465デフォルトの名無しさん
NGNG0466デフォルトの名無しさん
NGNGならばVB.NETになった今は不要。
0467463
NGNG簡単にレポートすると、WSHなんかに公開するオートメーションオブジェクトで、
IBindEventHandlerを使えばIConnectionPointとかを使わずに動的に
イベントハンドラを指定させたりできるというものでした。
どっかにドキュメント用意しとけよ！＞Ｍ＄
0468デフォルトの名無しさん
NGNG0469デフォルトの名無しさん
NGNGwindowsの既存のコンポーネントをガリガリ使うなら基礎知識として
知っておいたほうがいいかも。選択肢がいろいろ広がる。
まあこれからは.NETから使えるようになるだろうから、そこまでの
プライオリティがあるとは思えんがね。
0470デフォルトの名無しさん
NGNGCOMが最初に登場したのはOLE2ではなかったか?
インプレースアクティベーションを実現したかったから。
そのためにOLE WindowやData Objectがでてきて
COMというアイデアがでてきたと俺は解釈していた。(DDEはもう限界だ)
この流れにVBの話は1つもなしで、
今VBで自由に扱えるディスパッチインタフェースは
後になっての話でVB3で初めて使えるようになった。
さらに後になってインプレースアクティベートが発展して
OLEコントロールというしくみに発展する。
間違っていたらすまん。
0471デフォルトの名無しさん
NGNG0472デフォルトの名無しさん
NGNG0473デフォルトの名無しさん
NGNG「プロパティ⇒メソッド」は成り立つが「メソッド⇒プロパティ」は成り立たんだろ。
まったく同じみたいな書き方するなって。
0474デフォルトの名無しさん
NGNG472は「プロパティはメソッド」と書いてあるだけで「メソッドはプロパティ」とは
書いてませんが。
0475デフォルトの名無しさん
NGNG(*ppFuncDesc) ->invkindが、
INVOKE_PROPERTYGETかINVOKE_PROPERTYPUTかINVOKE_PROPERTYPUTREFなら
そのファンクションはプロパティ。
INVOKE_FUNCなら、そのファンクションはメソッド。
OK?
0476デフォルトの名無しさん
NGNGと書いてますが。
0477デフォルトの名無しさん
NGNGITypeInfoって、どうやって取得するの？
0478475
NGNGIDispatch::GetTypeinfoあたりからどうぞ。
結局、プロパティとメソッドはともに(必ずしもとは言えないけどたいていは)
IDispatchからInvokeできる関数ディスクリプタ。
その関数ディスクリプタがPROPGETやPROPPUT, PROPPUTREFとマークされているものを
とりあえず、プロパティと呼ぶ。とりあえずというのはオブジェクトが
プロパティと主張しているだけでコントローラがプロパティとして扱うかは
別だから。でも扱わないケースを見たこと無いけどね。
関数ディスクリプタがFUNC(やMETHOD)とマークされていればそれはメソッドとして
扱ってくれということ。プロパティと同じでオブジェクトの心、コントローラ知らず。
あと異なる点は、同じ関数ディスクリプタを異なる種類(Invoke Kindというらしい)
で呼び出すことができるという点。同じ関数ディスクリプタに対してPUTとGETができる。
(PUTREFなんてのもあるけどおいておいて)
たいていはPUTしたものはそのままGETできるし、PUTによってオブジェクトの状態(色とか)が変わったりする。
場合によってはオブジェクト自身がプロパティを勝手に変更したりするが
この場合はIPropertyNotifyでコントローラに通知したりすることができる。(うる覚え)
必ずしもPUT, GET両方ともサポートする必要は無し。どっちか片方なんてのはザラ。
読み取り専用プロパティなんていうのは、GETのみね。
今日のところはこの辺でカンベン。
眠くてなに言っているのか自分でもよくわかんなくなった。
おやすみ、またあとで。
0479デフォルトの名無しさん
NGNGありがとう。
0480IUnknown
NGNG同義に捉えてはいけないんだよね。それがいつも混乱の元になる。
472〜474のやり取りではそれが浮き彫りになってるね。
ひとつ気になったのはプロパティとメソッドの違いを問う人が、いきなり
475氏の説明を読んで理解できんのかな？って思う。「ありがとう」って
書いているし、要らぬお世話かな...。
0481477=479
NGNG＞＞ITypeInfoって、どうやって取得するの？
＞IDispatch::GetTypeinfoあたりからどうぞ。
これに対しての「ありがとう」です。
後半はよくわかりませんでした。
わからないと言えば他にも。
各メソッド／プロパティで設定したり取得したVARIANT型の変数の
開放は誰が行うべきなのか？とか。
getで得たものは自分で開放すべきなのはなんとなくわかりますが・・
0482デフォルトの名無しさん
NGNG0483デフォルトの名無しさん
NGNG平たく言えば、オブジェクトがそれをプロパティと言えばプロパティ。
メソッドといえばメソッド。
プロパティは同じ関数をGET/PUTと違う種別で呼び出せる。
メソッドの呼び出す種別は一種類だけ。
ということです。眠くなくても何言っているのかわからんね。
>各メソッド／プロパティで設定したり取得したVARIANT型の変数の
>開放は誰が行うべきなのか？とか。
>getで得たものは自分で開放すべきなのはなんとなくわかりますが・・
質問の意図はおそらく、VARIANTそのものの開放ではなく
BSTR* VARIANT::pbstrValのようにポインタの先に値の実体が
あるようなVARTYPEで、そのポインタの先の領域はだれが開放するのか
ということだろう。getでもらうにしても、あらかじめ
VARIANT構造体を渡してそこに入れてもらうしかないし。
パラメータの受け渡しにかぎらず
VARIANTについては以下のような単純なルールを守っていれば問題ないかと。
1.VARIANT構造体の実体を宣言したら、それに対してVariantInit()すること。
例：VARIANT var; VariantInit(&var);
2.VARIANTに値を入れる場合は、前もってVariantClear()しておくこと。
VariantClearはVariantのvtにあわせて、中身の開放も行ってくれる。
例：VariantClear(&var); var.vt = VT_I4; var.lVal = 2222;
VariantCopy()を使う場合はコピー先にVariantClearが行われるので不要。
3.VARIANT構造体の実体を消す(あるいはauto変数で自動的に消えそうな)場合は
前もってVariantClear()しておく。でないとリークする。
最終的に開放の責任を負っているのはそのVARIANT型の変数を割り当てた人。(ルール3)
VARIANT型の割り当てだよ、pbstrのようなVARIANTの中身の割り当てでは無いよ。
もらった側に最終的な開放の「義務」はない。
ただ、Byref渡しがあるので開放してはいけないということではない。(ルール2)
もらったVARIANTの中身を別の値、はては別のvtにする場合もあるので
その場合は中身を開放する必要があるんで。
渡す場合でも渡される場合でも、このルールに従えばいいと思う。
長くてすまん。間違っていたらすまん。だれかフォローしてくれ。
0484IUnknown
NGNG言いかえるならば「同じ関数名」ですね。get_、put_ が呼び出している
関数は異なる関数です。
VARIANTについては
「初期化する前のVARIANTにVariantClear()を行ってはならない」
VariantClear() は渡されたVARIANTを意味のあるものとして解釈するため、
初期化前のでたらめなデータが入っているVARIANTに対して使うと
無意味な参照を開放しようとしたり何が起こるかわからない！
（VARTYPEの解釈次第）
「クリアされていないVARIANTにVariantInit() を行ってはならない」
VariantInit() は渡されたVARIANTを意味の無いものとして解釈するため
BSTR やオブジェクト等のデータを保持しているVARIANTに対して使うと
これらは開放されること無くメモリに残り続けることになる。
って具合ですかね。当たり前のことですけど。
0485ななしー
NGNG他のオブジェクトのインターフェースを返すとき
どうやって宣言してますか？
自分としては、IFooとかを返したほうが良いような気がするのですが、
いろんなサンプルでは、ほとんどIDispatchとかVARIANTで返してるので、
なんでだろう？と思いました。
0486479
NGNG大変為になりました。
0487475
NGNG>>484 フォローサンキューです。なのでフォロー返しです。
弁明すると、1つの関数 = 1つのDISPIDに対してという意味でして、、
get_, put_で関数が分かれているのはデュアルインタフェースで
組まれているインタフェースのケースですね。
(というか、今時IDispatchを実装するのにデュアルが普通でしょ?)
この場合はvtblの要素がget_, put_で二つに分かれているので
関数が二つ必要ということです。(当たり前のなりゆきですが)
名前が、プロパティhogeに対してget_hogeとput_hogeになるのは
midlがそういうヘッダファイルを生成するから。
>「初期化する前のVARIANTにVariantClear()を行ってはならない」
それ以前にVariantInit()されていないVARIANTはVARIANTで無い
ということでしょう。当然他のVariantXxxx()にも
VariantInitされていないVARIANTを渡してはいけない。
>>485
メソッドやプロパティという単語が出てきているから
IDispatch経由ということでいいでしょうか？
それなら、IFooのようなオリジナルインタフェースは
引数に指定できないから。
渡すにせよ、もらうにせよ
パラメータに指定できるインターフェースは
(VARIANTの中身を含めて)IDispatchかIUnknownしかない。
なので、IDispatchかIUnknownを受け取った側でQueryInterfaceして
本当にIFooかを確認すればいいかと。
ところでスレの趣旨からしてrawなCOMの場合の話でいいんだよね?
0488デフォルトの名無しさん
NGNGunixでいうraw/cockedの関係？
0489デフォルトの名無しさん
NGNG0490475
NGNGすんません。説明不足です。
IDispatchの話にはVB辺りを絡めて考えている人もいると思い、
「VBでのCOMではなく、>>1 に従って、生(raw)のCOMでいいんですよね?」
ということです。
0491デフォルトの名無しさん
NGNGlate binding以外にIDispatchの利点てありますか？
0492デフォルトの名無しさん
NGNGIDispatchExとか言ってみるテスト。
0493475
NGNG「IDispatchってなんで必要なんだろう?」
と疑問におもっていた。で、俺流の解釈は
1. インタプリターだとこういうほうが扱いやすいのか
と自分を納得させていましたが、
いまや、VBでさえ、IDispatchなんて関係なく
カスタムインタフェースを呼べる、実装できる。
(oleautomationの制限はあるけど)
2.中間コードも作らない純粋なインタープリターだと
カスタムインタフェースを「呼び出す」のはなんとかできても
カスタムインタフェースを「実装」するには難しいと思う。
あらかじめ、全メソッドがわかっていないとvtblを作ることができないので。
その点、IDispatchは、メソッド名を問われた時点で考えれば
いいからやりやすい。
VBは開発環境で実行してもこっそりコンパイルしてコードを作って
動かしているような感じがするので、純粋ともいえないと思う。
3.「何にも考えなくてもマーシャリングできる」
（でもlongにポインタなんか入れたらダメだけど)
とも思いつつも、
カスタムインタフェースでも
ほぼ、自動的にマーシャラを用意できる。
結局、利点は2かな？
0494デフォルトの名無しさん
NGNGインターフェイス。以上。VBがIUnknownを扱えるようになったのは
ずっと後の話。
0495IUnknown
NGNG確かに。
VBScript の Class ステートメントの定義から作られる
オブジェクトなんかは内部的には IDispatchEx 経由で
アクセスするからね。正直このステートメントの実装を
可能にするために IDispatchEx は出来たんだろうね。
（いやまあ、推測だけど...。）
0496475
NGNG>何を理由かこつけてんの?
いや、理由をかこつけているのではなく
IDispatchを使う利点をかこつけているのですが。
>IDispatchはVBのためにVBチームが作ったインターフェイス。
そうですか。うすうすは感じていましたが。知りませんでした。
>VBがIUnknownを扱えるようになったのはずっと後の話。
「いまや、VBでさえ、IDispatchなんて関係なく
カスタムインタフェースを呼べる、実装できる。」
の「いまや」でその辺を示していたんですが。
あまりハッキリして言っていませんでしたね。すみません。
私の記憶では、VBでのCOMサポートはVersion3で
IDispatchドライバになることができた。
Version4でIDispatchオブジェクトになれて
Version5で制限ながらIUnknownオブジェクトになれる。
でしたっけ? 実はVB3って使ったことないんですが
OLE2 SDKについていたDISPTESTとかいう
テスト用のオートメーションドライバが
VB3のサブセットということを聞いたことがあるので。
0497デフォルトの名無しさん
NGNG#define _WIN32_WINNT 0x0400
#define WINVER 0x400
#include <windows.h>
#include <tchar.h>
#include <comdef.h>
#include <objbase.h>
#undef DialogBoxW
#pragma comment ( lib, "Rpcrt4.lib" )
#import "xl5jp32.olb" \
rename("DialogBox", "DialogBoxForExcel") \
rename( "RGB", "RGBForExcel")
int foo()
{
CoInitializeEx(0, COINIT_MULTITHREADED);
Excel::_Application *pRawExcel = NULL;
VC6で上のコードをビルドすると、Excel::_Application の行で
C:\proj\src\libexcel\libexcel.cpp(18) : error C2039: '_Application' : 'Excel' のﾒﾝﾊﾞではありません。
C:\proj\src\libexcel\libexcel.cpp(18) : error C2065: '_Application' : 定義されていない識別子です。
なかんじのエラーが出てしまいますが、何がまずいんでしょうか?
C++からexcelのセルがいじれてマクロが呼べればどのようなやり方でもいいんですけど、
そのへんから拾ってきたコードも、MSDNのサンプルもろくにビルドできずに困ってます。
0498デフォルトの名無しさん
NGNGc:\proj\src\libexcel\debug\excel9.tlh(1194) : error C2504: '_IMsoDispObj' : 定義されていない基本ｸﾗｽが宣言されています。
みたいなエラーがたくさん出てきます。
はひゅー
0499デフォルトの名無しさん
NGNGCoInitializeEx(0, COINIT_MULTITHREADED);
Excel::_ApplicationPtr pRawExcel( __uuidof( Excel::Application ) );
これでいかないか？
タイプライブラリをインポートすると、生のインターフェイスの代わりに
スマートポインタ版インターフェイスが定義されるはず。
_com_ptr_t<>ってやつ。インターフェイス名にPtrと付く事に注意。
スマートポインタなんで普通NULLは入れないな。
0500デフォルトの名無しさん
NGNGオートメーションやアクテブXの存在理由がイマイチわからん。
使うこともないし。何の意味があるのこれ？
C++を使う上で、無意味ともとれる決まりごとが多くてかなわん。
VBとかで使う為に必要なんですよとかそんなの理由になるのか？
.NETの本にCOMが難しいのは、本来OSが受け持つサービスを
自前で用意しなければならないからだとか書いてあったが正しくその通り。
0501デフォルトの名無しさん
NGNG> VBとかで使う為に必要なんですよ
.NETもそういう決まりごとでがんじがらめになってるけど、
コードを書く側にとって見えなくなってる。それがCOMとの違い。
COMは負担が大きすぎた。
0502497
NGNGありがとーん
あの後、MS09.olbとかVB6EXT.olbとかいること発見したんで、EXCEL9.olbを
使うように戻しました。
#import "C:\Program Files\Microsoft Office\Office\MSO9.DLL" \
rename("DocumentProperties", "DocumentPropertiesXL")
#import "C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB"
#import "C:\Program Files\Microsoft Office\Office\EXCEL9.OLB" \
rename("DialogBox", "DialogBoxXL") \
rename("RGB", "RBGXL") \
rename("DocumentProperties", \
"DocumentPropertiesXL") \
no_dual_interfaces \
exclude("IFont","IPicture")
int foo()
{
CoInitializeEx(0, COINIT_MULTITHREADED);
Excel::_ApplicationPtr pRawExcel( __uuidof( Excel::Application ) );
pRawExcel->Quit();
return 0;
}
でもやぱーり、
c:\proj\src\libexcel\debug\excel9.tli(3731) : error C2511: 'PutOnDoubleClick' : ｵｰﾊﾞｰﾛｰﾄﾞされたﾒﾝﾊﾞ関数が '<Unknown>' にありません。
なんてのが出てきてお手上げ状態です。
web上にも完全なコードやOLB間の依存関係の情報があまりないところを見ると、
#importではみんなうまくいかなくてあきらめちゃってるんじゃないかと思う次第であります。
0503499
NGNG折れも試しに作ってみたが、一応コンパイルは通ったよ。
動くかどうかは試してないけど。
普通にATL COM AppWizard でexeサーバー作ってる。
// Test.cpp : CTest のインプリメンテーション
#include "stdafx.h"
#include "EXCEL9_TEST.h"
#include "Test.h"
#import "E:\Program Files\Microsoft Office\Office\MSO9.DLL"
#import "E:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB"
#import "E:\Program Files\Microsoft Office\Office\EXCEL9.OLB" rename("DialogBox", "DialogBoxXL") rename("RGB", "RBGXL")
/////////////////////////////////////////////////////////////////////////////
// CTest
STDMETHODIMP CTest::a()
{
CoInitializeEx(0, COINIT_MULTITHREADED);
Excel::_ApplicationPtr pRawExcel( __uuidof( Excel::Application ) );
pRawExcel->Quit();
::CoUninitialize();
return S_OK;
}
0504497
NGNGｳﾜｰﾝ
#includeを付けたりはずしたらりしてたらビルドできるようになったよー
手順はこうです
>>497をふつうのWin32 Console exeで作成
↓
いろいろいじるがﾊﾟｰｲ
↓
2chに泣きつく
↓
>>503を読んで、ATL COM AppWizardでexeｻｰﾊﾞを作ってコンパイル
↓
Σ(ﾟдﾟlll)ｶﾞｰﾝ動くよ
↓
#includeしてるヘッダが関係してるかと思って>>497に#include <atlcom.h>とか
#define STRICTとかいれてみる
↓
Σ(ﾟдﾟlll)ｶﾞｰﾝコンパイル通るよ
↓
元の>>497に戻してビルド
↓
Σ(ﾟдﾟlll)ｶﾞｰﾝコンパイル通るよ
という次第です。
コンパイラが作成する tlhとかが壊れてたのかなーと思ってみたりして。
0505497
NGNGところで、excel 97/98/2000/2002を同じようにC++側から操作したい場合、
ソースは一個で何とかなるんでしょうか?
それぞれのofficeのバージョンごとにolbとか取り込まなきゃいかんのでしょうか?
0506499
NGNG折れはアマゲープログラマなんで
EXCELのことは全然わからんのですよ。（ ´Д⊂
ただやっぱ、COMなんだから
EXCEL97〜EXCEL2002が
同じCLSIDを持つコーポネントを利用しているのなら
最新のOLD1つを対象に組むだけで良いんのではないかな？
0507497
NGNG__uuidof( Excel::Application )
のところがポイントですかね。
Excel97で持っているUUIDを渡すべきかな?
場つなぎ的なサンプルしかないのでこれも試行錯誤するしかないですね。
0508デフォルトの名無しさん
NGNGが、97〜2002で全く挙動が一緒だという保証はないと思うが。
0509497
NGNG"Excel.Application" みたいなのがバージョンなしのProgIDなんでしょうか。
やりたいことはセルの値の取得と設定、マクロの起動くらいなので
バージョンには依存しないと思われます。
最新のOLD+バージョン無しProgIDの線で攻めてみます。
0510499
NGNG調べまくってわかりました。
EXCEL95がxl5jp32.olb、
EXCEL97がEXCEL8.olb、
ELECEL2000がEXCEL9.olbなんですね。
それで折れが調べた限り
xl5jp32.olbとEXCEL9.olbは
コーポネント上の互換性は無いみたいです。
インターフェイスやそのメソッドとかは
なんとなく似てるんですが。
自分のWin2000ではxl5jp32.olbのインターフェイスを呼ぶと
何故か失敗するので確かめることはできなかったんですけど。
EXCEL8.olbは手元に無いのでわかりませんでした。
0511497
NGNG0512デフォルトの名無しさん
NGNGBCCからも使いたいっぺ。
0513デフォルトの名無しさん
NGNG当然だが、C++からは直でタイプライブラリは読めないので
C++のソースファイルへの変換が必要。
#importディレクティブは、OLBファイルから
TLHとTHIというC++のヘッダとソースを作り出す。
それに加え、OLBファイルからツールを使ってIDLファイルを作成し、
IDLファイルからMIDLコンパイラを使ってC++ヘッダをコンパイルする方法もある。
上記二つのどっちかのC++ソースを、何らかの方法でゲットしてBCCで使えるかどうか
試す。
又は、COMの機能を使って動的にタイプライブラリを読み出す事も可能。
LoadTypeLibEx()でITypeLibインターフェイスを取得する方法。
0514デフォルトの名無しさん
NGNGCLSIDFromProgID( "Excel.Application" )ではだめでしょうか？
だめなら、全てIDispatch経由でアクセスするしかないでしょうか...
0515499
NGNG497？
ならすいません。ウソこいてました。
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経由以外ないと
の間違いです。
0517514
NGNG古いexcel等は確かおっしゃるとおりdispinterfaceしか定義されていなかった
と記憶しています。
そこで >>497 さんは #import を使っているみたいですから、#import すれば
Dispatch経由でアクセスしてくれるラッパが自動的にできないかなーと思ったしだいです。
今手元に環境が無いのでおぼろげな記憶だけですが..
だめならやっぱり >>514 に書いたとおり、
せめて excel のクラスIDぐらいはバージョン非依存で取得して、
あとは自分で IDispatch 経由でアクセスするしかないかと..
0518497
NGNGありがとーございましし。
>xl5jp32.olbと互換性を持たせるなら、IDispatch経由以外ないと
コードレベルでの互換をとるなら、という意味ととってよいでしょうか。
OLBは今ある最新のものを使うとして、それがofficeのバージョンに
依存するかどうか、が一番の焦点だったのですが、問題なさそうですね。
とりあえず、バージョン非互換のクラスID+OLBのインポートで
テストしてみます。
2chで初めて人に感謝しました。
0519sage
NGNGDelphi6 PersonalでCOMが作れるか調べていたのですが、
Personalにはウィザードがないようです。ベタに作る手は
あると思うのですが、Googleでもあまり情報がなく。
VC++は歯が立たないので、ほかの言語でCOM作って遊ぼうと
している次第で。WSC、VB6、.Net(C#)は実践済み。
0520デフォルトの名無しさん
NGNG0521デフォルトの名無しさん
NGNGWSC(わんだーすわんからー？)/C# がCOMと関係あるとは思えない
0522519
NGNG>>520
Cの経験がないのです。ニセモノです私（恥）
>>521
ASP/スクリプト環境で使うことを考えていたのです。
作ったものが呼べるとわかればあとは何とかなると思っています。
WSCはWindows Script Componentです。あまり流行ってませんが。
スクリプトのかたまりをCOMとして呼べる代物。
C#/.netはinterop経由でアセンブリをCOMとして呼べます。
VBならActiveX DLLでCOMのこと何も知らずに作れるので、
気楽なものかと思っていたのですが。このスレ読む限り
非常にレベル高そうですね。
ここまで書いてCOMの意味を誤解している気がしてきました。
0523デフォルトの名無しさん
NGNG知識として知っておくのはいいかもしれんが、自分でやることはないだろうなあ。
DelphiでのやりかたはDelphi関連のスレで聞いた方がいいとおもう。
なんらかのサポートがあったと思うがよく知らない。
0524519
NGNG0525デフォルトの名無しさん
NGNGやるならオートメーションは意図的に省いて
それ以外のアーキテキチャを勉強を勉強すべき。
マーシャリングとかそこらへん。
俺は確信に至った。
IDispatchやIDispatchExなんてのは
明らかに死に行く技術だ。存在価値ゼロ。
0526ななし
NGNGそこまで読み切れる判断力がうらやましい。（決して皮肉とかじゃないですよ）
VBがやっとな俺の頭脳では、高度な技術の是非までは残念ながら判定できない。(泣
0527sage
NGNGなんとかうまいことC++からExcelを操作することができるようになりましし。
重ね重ねお礼を申し上げます。
0528ななし
NGNG0529デフォルトの名無しさん
NGNG君はまず日本語を勉強すべき。
0531デフォルトの名無しさん
NGNG0532デフォルトの名無しさん
NGNGこういうのってIDispatchのおかげじゃないの？
0533デフォルトの名無しさん
NGNGWeb制作板はscriptの話ばっかりで参考にならなくて。
0534デフォルトの名無しさん
NGNGこんなスレもあるよ。
http://pc.2ch.net/test/read.cgi/tech/982930049/l50
0536デフォルトの名無しさん
NGNG0537デフォルトの名無しさん
NGNGしにくいかもしれないですけどVBとVCで作ったCOMの比較とEJBを比較するとどの
程度の速度差になるのでしょうか？やはりATLなどでVCのCOMがあまりはやらない
のはVBなどでも満足いく速度だから？
0538デフォルトの名無しさん
NGNG>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デフォルトの名無しさん
NGNG0543デフォルトの名無しさん
NGNGクライアントにコネクションポイント実装させるのもなあ。
しかし本気でこの型制限にはいらつくよ。何も出来やしねえじゃねえか。
0544デフォルトの名無しさん
NGNG0545デフォルトの名無しさん
NGNG■ このスレッドは過去ログ倉庫に格納されています