アカウント名:
パスワード:
俺もiTextやApache PDFBoxでゴチャゴチャとpdfを扱った経験はいくつもあるけどExcelのマクロだって、使ってみりゃいい具合に強力なんよな。VBAはちょっと慣れないけど。セル結合もセルの幅も背景色も、ロジックで調整し放題だし。DBにも普通に繋げられるし。他のドキュメントも開けるし。
相手が事務方なら、エンドユーザ自身に所望のモック作らせてそれをテンプレに自動生成するのが手っ取り早いですからね。用途に応じて適切な工具があるのに、イメージだけで毛嫌いするのは勿体ない。
何かの記事で読んだけど最も有効活用されているシステムは担当者が自作したExcelマクロだ
ってのがあったがExcelかどうかは本筋ではないとして、顧客が本当に欲しかったもの、が最も実現しやすいよな
欲しくないものが作られはしないってだけで、こういうこともしたいけど(APIや言語の制限やスキル不足で)出来ないので妥協したって物も数多く存在するかと……
そんなのExcelマクロに限った話じゃないだろ
限った話じゃないと書いてあるのに
最大の問題はVBAは遅いってことだ。
マクロは自分一人で管理する分にはいいと思うよ。VBA環境はいい所もある。
ExcelVBAの地獄なところは、・テキストがxlsmに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)・テストが書けない(工夫(ry・エラー行が特定できない事がある・謎のリソース不足で落ちる(VBAで不足するほどリソースを大量に使う発想がそもそもおかしいのだが)・TryCatchがない・動的配列が無い(正確にはそういったものは皆無ではないがReDimとかいつの時代のアレだ)・辞書(連想配列)が使い辛い・当然ラムダとかない、というか関数参照が碌に扱えないのでちょっと本腰入れてプログラム書こうとか
動的配列はReDimでどうにかするしかないですね。初期化してないVariantでも安全に使えるUBound作ったり色々対象してます。連想配列はDictionary使ってますけど、言語標準機能じゃないのは確かに気持ち悪いですね。
3行以上読めないやつ向けに要点だけを引用して貼っておこう> 工夫すればできるが労力が無駄
3行以上読めない、じゃなくて3行以上読まない、じゃないかな。何故書いた文章を漏れなく隅々まで読んでくれると思っているのだろうか。暇人ならではの発想?
読むだけならばともかく、議論に参加しながら読まないのはダメでしょう。
こんな場末の掲示板サイトで、議論に参加するって意識なんか端から無いんじゃ
ここは議論する場所じゃなくて雑談する場所だからな。
コンパクトに要点をまとめられない奴は議論に参加する資格なし、ってことじゃない?
楽しくおしゃべりしていただけなのに、議論好きのレッテルを貼られるぞ?
書いてあるのを読んでないだろおまえ、と言われたら、必死になって「だって雑談だし」って顔真っ赤にして三連投しちゃうような人は、議論どころか雑談にも向いてないと思う。
自分の環境しか見えてないバカ発見。こうですか?
ReDimはPreserveつけるととんでもなく重いから、基本的に動的配列を使いたいときはCollectionを使うなー。んで、本当に「配列」にしたいときは、要素数が確定してから静的配列を宣言して値を代入してます。
Excel内部にはマクロを持たせず、PowerShell等、外部からExcelを操作したらどうかと検討したこともあったけど利用する側の利便性も考慮したベストな方法が見つからない。
外部からだと、1変数参照に「ExcelOpen→参照→ExcelClose」とかなるからのろさダイナマイトになるでしょう。#外部からシートをなめるのと、検索条件をシートの空きに書いて#一気にVLookupするのとの時間差がそれ。
うーん、dde操作イメージかな?
普通は、COM操作になるので、参照毎にOpen,Closeする必要なんてないと思いますよ。
>参照毎にOpen,Closeする必要なんてない
たしかにOpen,Closeというのは言い過ぎだったかも知れませんが、内部からCells(,)を呼ぶのと、外部から呼ぶのでは速度が段違いです。
1000行位なめると、その差は歴然でした。Open,Closeはうそかも知れませんが、なんらかのオーバーヘッド(内部なら保持可能な参照を、外部からでは持ち切れず、一々、参照を取り直しとか)が有るのは事実です。
内部(COMインターフェースも不要)と外部(COM操作、Excel.Applicationへの参照を変数に入れ、それに対する操作)での比較です。それはご指摘の通りです。
それがなきゃWSH/HTA(JScript)+polyfillでそこそこ快適なんだけどねぇ……簡単なデータ読むだけなら全選択コピーからのクリップボード読みでまぁまぁ行ける。メタ文字対策するならCSVとかでファイルに吐かんと駄目だろうけど。書式とかも読むならどうしようもない。
遅くなる原因はExcel由来オブジェクトの実体が全部Excelプロセス内に居て、配列アクセス含めた全操作が全部リモートプロシージャコールかなんかになってるんじゃないかと。COM経由でマクロ叩いてデータ変換掛けてプリミティブでデータ貰えれば良いんだが、COMから楽に叩けるのはクソ古いExcel互換マクロでWin32API呼ぶ位しか用途の無いやつだったり。
マーシャルが遅いので1000回取ったら遅いrangeだったかで一気にどかっと取ればだいぶ速いよ
識者に教えていただきたいのですが、VBAでCells(,)とやるのと、外部のプログラムから相当の処理をやるのと速度に違いがでるのでしょうか?
VBAのプログラムはExcelファイルの中に組み込みという違いがありますが、技術的にはどっちもCOMで通信してるのであってそこの性能は変わらないとおもってます。
アウトプロセス(OLEサーバ)とインプロセスの差では無いでしょうか?
後者ならポインタを保持すれば参照になるでしょうけれど、前者は先方のプロセスのポインタは無意味です。意味のある様に一々、解釈しなおさないといけないのでしょう。そして、Excelはその再解釈がとくに重い(accdbなどと比べて)データ構造だからではないかと想像します。
それならxlsxをXMLデータとして直接扱った方が速いでしょ
すごい! 有難うございます。
Book1\xl\worksheets\sheet1.xmlを7zで解凍:
<?xml version="1.0" encoding="UTF-8" standalone="true"?><worksheet xr:uid="{C1B9B2EA-E173-4F57-A2EB-92CA6B3B9CD1}" xmlns:xr3=略 ><dimension ref="E20:F20"/>
<sheetViews>
<sheetView workbookViewId="0" tabSelected="1"><selection sqref="F21" activeCell="F21"/></sheetView></sheetViews><sheetFormatPr x14ac:dyDescent="0.4" defaultRowHeight="18.75"/>
<sheetData>
<row r="20" x14ac:dyDescent
そんな原始的な事しなくても、OpenXML(MS謹製)やEPPlus(サードパーティー)などを使えば簡単に参照、編集できますよ。
特に後者はデータ構造がExcleオブジェクトに似た構成になっているので直感的に触れますし。
COMアドインにしてしまうのが、簡単だと思いますよ。
配布もclickonceで簡単にできますし。
OfficeアプリのOLEオートメーションは本当に便利なんだけどそれを頑なに「VBAで」扱おうとするIT土方がこういう風評ばらまいてるんだよな
VariantもOptionalもVBAが先鞭だし、別に言語に大した瑕疵が有る訳でも無し、なんでVBAが悪いのか?まぁ、32ビットDOS上でなら、どんな言語もぼろぼろだったのは事実でしょうが。
当時の話なんかしてないし、VBAの短所は元コメがさんざん書き散らしてるだろ何に反論してるんだ?
だから、たかがそれだけじゃないか、と言っている。短所の無い言語なんか無いのに、永久失格的に言うことも無いじゃないか、と反論している。
「本当に便利」か、再考するべき。そのシステム、本当にOfficeベースで構築するのが適切なのか。一見手軽と思われるが、工数は本当に削減されているのか?顧客の幸福は?
Officeから脱却する選択肢を持たないエンジニアこそ典型的な「IT土方」であろう。
お前の言う「そのシステム」がどういう条件なのかは曖昧すぎるけど「OLEオートメーションが本当に便利」なことに特に間違いは無いだろ
とにかく否定したいために否定できる土俵を漠然と定義して語るのは自己満足でしかないぞ
「OLEオートメーションが本当に便利」って、「ライブラリは本当に便利」って言われてるのと大差ない。便利なのはOfficeでなく、OLEオートメーションというインターフェースの方だと言いたかったという事かい?それが便利というのは否定はしないけど、そういう仕組みのものがそう動くのが便利だという発想はちょっと無かった。
外から制御できるとしてもOfficeを使うことはOfficeに縛られること。Officeを従えるでなく、Officeに使われるようなシステム開発思想はいかにもIT土方らしいよね、と言ってるだけだよ。君は違うんだね。それならいい。
なんだかもう言ってることがヴィーガンみたいだな憎むのが目的化してて、ある意味こいつもOfficeに縛られてる
RPAソフトのスクリプト書いてる人の意見が待たれる。
便利だけど、ファイルサーバーの共有フォルダのあるフォルダに全部ある、xlsxファイル200個から、特定のセルの値10個をもって来るのに2時間以上かかる。データ参照は、RDBのリモートインターフェースが、やはり有利なので、ぞうさんも好きだが、きりんさんも好きなのがいいし、最近ならクラウドもいい。
「自動車は便利だけど、東京から大阪まで行くなら新幹線が、やはり有利」
何にでもサジ加減と得手不得手があるわな
>テキストがxlsmに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)>編集環境がVisual Basic Editorに縛られる
Exportすれば良い。去年の後半から初めてVBAを触りだし、今は数万行のマクロを組んでいるけれど、テキストエディタ上で編集して、VBEに貼り付けてます。完成したらExport。VBEからテキストエディタにコピペしないのはコピペの方向を一方通行に限定することで完成品にミスが紛れ込むのを防ぐ目的がある。
ActiveWorkbook.VBProject.VBComponents(n).Export(出力パス)?
後、Formもテキスト化した方がいい。(Functionの唯一の参照先がFormのプロパティで、VBAから使っていないから消して、わーーーとなったりしない様に)ただし、AccdbではFormのテキストがUnicode(16ビット)で出ますので注意。(ADODBにコード変換機能有(ただしFile To File))
Exportを自動化したいなら、xlmやxlsmに含まれるvbaproject.binをデコードするツールを使った方が良いと思う。
おまえら元コメの「(工夫すればできるが労力が無駄)」を無視しすぎ
そこに突っ込む人は「労力が無駄」を無視しすぎ
他のプログラミング言語や環境における、もろもろの習得コストや構築コストや導入コストを無視し過ぎ。例えば動作環境が事務方のPC前提なら、何が最適だと思う?
割合最近Officeオートメーションを触るようになりましたが、採用されている技術の古さが致命傷レベルだと思いますがそれを忘れればElectronとそう変わらないと思います。
さて、JavaScriptの地獄なところ、合ってるかわかりませんが…
・テキストがhtmlに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)・テストがconsole.log(工夫(ry・エラー行が特定できない事がある(JScript)・謎のリソース不足で落ちる(npmでlocal-chromiumを大量に使う発想がそもそもおかしいのだが)・TryCatchはcatchが分岐を持たない・動的配列が無い(プロパティへの特殊なアクセスである)
面白くもないし間違いだらけで突っ込むのも面倒臭い。ネタにする言語のチョイスからして下手くそ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
自分もそうするかもなあ (スコア:0)
俺もiTextやApache PDFBoxでゴチャゴチャとpdfを扱った経験はいくつもあるけど
Excelのマクロだって、使ってみりゃいい具合に強力なんよな。
VBAはちょっと慣れないけど。
セル結合もセルの幅も背景色も、ロジックで調整し放題だし。
DBにも普通に繋げられるし。他のドキュメントも開けるし。
Re:自分もそうするかもなあ (スコア:1)
相手が事務方なら、エンドユーザ自身に所望のモック作らせて
それをテンプレに自動生成するのが手っ取り早いですからね。
用途に応じて適切な工具があるのに、イメージだけで毛嫌いするのは勿体ない。
Re: (スコア:0)
何かの記事で読んだけど
最も有効活用されているシステムは担当者が自作したExcelマクロだ
ってのがあったがExcelかどうかは本筋ではないとして、
顧客が本当に欲しかったもの、が最も実現しやすいよな
Re: (スコア:0)
欲しくないものが作られはしないってだけで、
こういうこともしたいけど(APIや言語の制限やスキル不足で)
出来ないので妥協したって物も数多く存在するかと……
Re: (スコア:0)
そんなのExcelマクロに限った話じゃないだろ
Re: (スコア:0)
限った話じゃないと書いてあるのに
Re:自分もそうするかもなあ (スコア:1)
最大の問題はVBAは遅いってことだ。
Re: (スコア:0)
マクロは自分一人で管理する分にはいいと思うよ。VBA環境はいい所もある。
ExcelVBAの地獄なところは、
・テキストがxlsmに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)
・テストが書けない(工夫(ry
・エラー行が特定できない事がある
・謎のリソース不足で落ちる(VBAで不足するほどリソースを大量に使う発想がそもそもおかしいのだが)
・TryCatchがない
・動的配列が無い(正確にはそういったものは皆無ではないがReDimとかいつの時代のアレだ)
・辞書(連想配列)が使い辛い
・当然ラムダとかない、というか関数参照が碌に扱えないのでちょっと本腰入れてプログラム書こうとか
Re: (スコア:0)
動的配列はReDimでどうにかするしかないですね。初期化してないVariantでも安全に使えるUBound作ったり色々対象してます。
連想配列はDictionary使ってますけど、言語標準機能じゃないのは確かに気持ち悪いですね。
Re: (スコア:0)
3行以上読めないやつ向けに要点だけを引用して貼っておこう
> 工夫すればできるが労力が無駄
Re: (スコア:0)
3行以上読めない、じゃなくて3行以上読まない、じゃないかな。
何故書いた文章を漏れなく隅々まで読んでくれると思っているのだろうか。
暇人ならではの発想?
Re: (スコア:0)
読むだけならばともかく、議論に参加しながら読まないのはダメでしょう。
Re: (スコア:0)
こんな場末の掲示板サイトで、議論に参加するって意識なんか端から無いんじゃ
Re: (スコア:0)
ここは議論する場所じゃなくて雑談する場所だからな。
Re: (スコア:0)
コンパクトに要点をまとめられない奴は議論に参加する資格なし、ってことじゃない?
Re: (スコア:0)
楽しくおしゃべりしていただけなのに、議論好きのレッテルを貼られるぞ?
Re: (スコア:0)
書いてあるのを読んでないだろおまえ、と言われたら、必死になって「だって雑談だし」って顔真っ赤にして三連投しちゃうような人は、議論どころか雑談にも向いてないと思う。
Re: (スコア:0)
自分の環境しか見えてないバカ発見。
こうですか?
Re: (スコア:0)
ReDimはPreserveつけるととんでもなく重いから、基本的に動的配列を使いたいときはCollectionを使うなー。
んで、本当に「配列」にしたいときは、要素数が確定してから静的配列を宣言して値を代入してます。
Re: (スコア:0)
Excel内部にはマクロを持たせず、PowerShell等、外部からExcelを操作したらどうかと検討したこともあったけど
利用する側の利便性も考慮したベストな方法が見つからない。
Re: (スコア:0)
外部からだと、1変数参照に「ExcelOpen→参照→ExcelClose」とかなるから
のろさダイナマイトになるでしょう。
#外部からシートをなめるのと、検索条件をシートの空きに書いて
#一気にVLookupするのとの時間差がそれ。
Re: (スコア:0)
うーん、dde操作イメージかな?
普通は、COM操作になるので、参照毎にOpen,Closeする必要なんてないと思いますよ。
Re: (スコア:0)
>参照毎にOpen,Closeする必要なんてない
たしかにOpen,Closeというのは言い過ぎだったかも知れませんが、
内部からCells(,)を呼ぶのと、外部から呼ぶのでは速度が段違いです。
1000行位なめると、その差は歴然でした。Open,Closeはうそかも知れませんが、
なんらかのオーバーヘッド(内部なら保持可能な参照を、外部からでは持ち切れず、
一々、参照を取り直しとか)が有るのは事実です。
内部(COMインターフェースも不要)と外部(COM操作、Excel.Applicationへの
参照を変数に入れ、それに対する操作)での比較です。
それはご指摘の通りです。
Re: (スコア:0)
それがなきゃWSH/HTA(JScript)+polyfillでそこそこ快適なんだけどねぇ……
簡単なデータ読むだけなら全選択コピーからのクリップボード読みでまぁまぁ行ける。
メタ文字対策するならCSVとかでファイルに吐かんと駄目だろうけど。
書式とかも読むならどうしようもない。
遅くなる原因はExcel由来オブジェクトの実体が全部Excelプロセス内に居て、
配列アクセス含めた全操作が全部リモートプロシージャコールかなんかになってるんじゃないかと。
COM経由でマクロ叩いてデータ変換掛けてプリミティブでデータ貰えれば良いんだが、
COMから楽に叩けるのはクソ古いExcel互換マクロでWin32API呼ぶ位しか用途の無いやつだったり。
Re: (スコア:0)
マーシャルが遅いので1000回取ったら遅い
rangeだったかで一気にどかっと取ればだいぶ速いよ
Re: (スコア:0)
識者に教えていただきたいのですが、VBAでCells(,)とやるのと、外部のプログラムから相当の処理をやるのと
速度に違いがでるのでしょうか?
VBAのプログラムはExcelファイルの中に組み込みという違いがありますが、技術的にはどっちもCOMで通信してるのであって
そこの性能は変わらないとおもってます。
Re: (スコア:0)
アウトプロセス(OLEサーバ)とインプロセスの差では無いでしょうか?
後者ならポインタを保持すれば参照になるでしょうけれど、前者は
先方のプロセスのポインタは無意味です。意味のある様に一々、解釈
しなおさないといけないのでしょう。そして、Excelはその再解釈が
とくに重い(accdbなどと比べて)データ構造だからではないかと
想像します。
Re: (スコア:0)
それならxlsxをXMLデータとして直接扱った方が速いでしょ
Re: (スコア:0)
すごい! 有難うございます。
Book1\xl\worksheets\sheet1.xmlを7zで解凍:
<?xml version="1.0" encoding="UTF-8" standalone="true"?>
<worksheet xr:uid="{C1B9B2EA-E173-4F57-A2EB-92CA6B3B9CD1}" xmlns:xr3=略 >
<dimension ref="E20:F20"/>
<sheetViews>
<sheetView workbookViewId="0" tabSelected="1">
<selection sqref="F21" activeCell="F21"/>
</sheetView>
</sheetViews>
<sheetFormatPr x14ac:dyDescent="0.4" defaultRowHeight="18.75"/>
<sheetData>
<row r="20" x14ac:dyDescent
Re: (スコア:0)
そんな原始的な事しなくても、OpenXML(MS謹製)やEPPlus(サードパーティー)などを使えば簡単に参照、編集できますよ。
特に後者はデータ構造がExcleオブジェクトに似た構成になっているので直感的に触れますし。
Re: (スコア:0)
COMアドインにしてしまうのが、簡単だと思いますよ。
配布もclickonceで簡単にできますし。
Re: (スコア:0)
OfficeアプリのOLEオートメーションは本当に便利なんだけど
それを頑なに「VBAで」扱おうとするIT土方がこういう風評ばらまいてるんだよな
Re: (スコア:0)
VariantもOptionalもVBAが先鞭だし、別に言語に大した瑕疵が有る訳でも無し、
なんでVBAが悪いのか?
まぁ、32ビットDOS上でなら、どんな言語もぼろぼろだったのは事実でしょうが。
Re: (スコア:0)
当時の話なんかしてないし、VBAの短所は元コメがさんざん書き散らしてるだろ
何に反論してるんだ?
Re: (スコア:0)
だから、たかがそれだけじゃないか、と言っている。
短所の無い言語なんか無いのに、永久失格的に言うことも
無いじゃないか、と反論している。
Re: (スコア:0)
「本当に便利」か、再考するべき。
そのシステム、本当にOfficeベースで構築するのが適切なのか。
一見手軽と思われるが、工数は本当に削減されているのか?顧客の幸福は?
Officeから脱却する選択肢を持たないエンジニアこそ典型的な「IT土方」であろう。
Re: (スコア:0)
お前の言う「そのシステム」がどういう条件なのかは曖昧すぎるけど
「OLEオートメーションが本当に便利」なことに特に間違いは無いだろ
とにかく否定したいために否定できる土俵を漠然と定義して語るのは自己満足でしかないぞ
Re: (スコア:0)
「OLEオートメーションが本当に便利」って、「ライブラリは本当に便利」って言われてるのと大差ない。
便利なのはOfficeでなく、OLEオートメーションというインターフェースの方だと言いたかったという事かい?
それが便利というのは否定はしないけど、そういう仕組みのものがそう動くのが便利だという発想はちょっと無かった。
外から制御できるとしてもOfficeを使うことはOfficeに縛られること。
Officeを従えるでなく、Officeに使われるようなシステム開発思想はいかにもIT土方らしいよね、と言ってるだけだよ。
君は違うんだね。それならいい。
Re: (スコア:0)
なんだかもう言ってることがヴィーガンみたいだな
憎むのが目的化してて、ある意味こいつもOfficeに縛られてる
Re: (スコア:0)
RPAソフトのスクリプト書いてる人の意見が待たれる。
Re: (スコア:0)
便利だけど、ファイルサーバーの共有フォルダのあるフォルダに
全部ある、xlsxファイル200個から、特定のセルの値10個をもって
来るのに2時間以上かかる。
データ参照は、RDBのリモートインターフェースが、やはり有利
なので、ぞうさんも好きだが、きりんさんも好きなのがいいし、
最近ならクラウドもいい。
Re: (スコア:0)
「自動車は便利だけど、東京から大阪まで行くなら新幹線が、やはり有利」
何にでもサジ加減と得手不得手があるわな
Re: (スコア:0)
>テキストがxlsmに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)
>編集環境がVisual Basic Editorに縛られる
Exportすれば良い。
去年の後半から初めてVBAを触りだし、今は数万行のマクロを組んでいるけれど、テキストエディタ上で編集して、VBEに貼り付けてます。
完成したらExport。
VBEからテキストエディタにコピペしないのはコピペの方向を一方通行に限定することで完成品にミスが紛れ込むのを防ぐ目的がある。
Re: (スコア:0)
ActiveWorkbook.VBProject.VBComponents(n).Export(出力パス)?
後、Formもテキスト化した方がいい。(Functionの唯一の参照先がFormの
プロパティで、VBAから使っていないから消して、わーーーとなったり
しない様に)
ただし、AccdbではFormのテキストがUnicode(16ビット)で出ますので
注意。(ADODBにコード変換機能有(ただしFile To File))
Re: (スコア:0)
Exportを自動化したいなら、xlmやxlsmに含まれるvbaproject.binをデコードするツールを使った方が良いと思う。
Re: (スコア:0)
おまえら元コメの「(工夫すればできるが労力が無駄)」を無視しすぎ
Re: (スコア:0)
そこに突っ込む人は「労力が無駄」を無視しすぎ
Re: (スコア:0)
他のプログラミング言語や環境における、もろもろの習得コストや構築コストや導入コストを無視し過ぎ。
例えば動作環境が事務方のPC前提なら、何が最適だと思う?
Re: (スコア:0)
割合最近Officeオートメーションを触るようになりましたが、採用されている技術の古さが致命傷レベルだと思いますが
それを忘れればElectronとそう変わらないと思います。
さて、JavaScriptの地獄なところ、合ってるかわかりませんが…
・テキストがhtmlに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)
・テストがconsole.log(工夫(ry
・エラー行が特定できない事がある(JScript)
・謎のリソース不足で落ちる(npmでlocal-chromiumを大量に使う発想がそもそもおかしいのだが)
・TryCatchはcatchが分岐を持たない
・動的配列が無い(プロパティへの特殊なアクセスである)
Re: (スコア:0)
面白くもないし間違いだらけで突っ込むのも面倒臭い。
ネタにする言語のチョイスからして下手くそ。