Excel VBA 質問スレ Part56

**デフォルトの名無しさん** · 2018/08/23(木) 07:25:24.98

ExcelのVBAに関する質問スレです
コード書き込みや作成依頼もOK

※前スレ
Excel VBA 質問スレ Part55
http://mevius.5ch.net/test/read.cgi/tech/1532236398/l50

**デフォルトの名無しさん** · 2018/08/25(土) 11:38:28.45

>>106
？
新規Excelブックに出力して出力した全行をテーブルレイアウトに変更する
て書いてあるじゃん

**デフォルトの名無しさん** · 2018/08/25(土) 11:40:32.66

Excelから始まってExcelに終わる
Excel以外の外部環境とは隔離
これがエクセル案件
VBAはエクセル案件のためにある

**デフォルトの名無しさん** · 2018/08/25(土) 11:54:03.16

>>107
何故か見落としてた。すまんな。

**デフォルトの名無しさん** · 2018/08/25(土) 12:32:54.50

>>108
データ量を考えた場合、RDBとの連携は認めても良いとは思うのだけどね。いちいち>>104みたいにRubyを持ち出すバカは別にして

**デフォルトの名無しさん** · 2018/08/25(土) 12:34:48.30

>>110
認めたら他の言語が優位になってしまう
エクセルでやるならエクセルだけで完結させる
これは絶対的なルールで例外は認められない

**デフォルトの名無しさん** · 2018/08/25(土) 12:41:34.89

普通にdll作ってexcelからdllの関数読んで作るような案件ないくらでもあるかな
追うのが困難な知恵遅れ大量ｸｿVBAを知恵遅れが書くのを防止することもできる

excelでvbaを書くぐらいしかできない知恵遅れ無能に
できるだけ余計な事をさせない事前策にもなってる

**デフォルトの名無しさん** · 2018/08/25(土) 13:28:24.31

自分用のちょっとしたツール
　スプレッドが必要
　　操作補助が必要
　　　補助の内容が複雑->.NET(COM)+VBA(イベント, フォーミュラひも付けのみ)
　　　補助の内容が単純->VBA
　　操作補助が不要->自分の環境で使用可能な任意の言語
　スプレッドが不要->自分の環境で使用可能な任意の言語
他人に配布するツール
　依存関係(※1)が揃っているとわかっている->その依存関係で使用可能な任意の言語
　依存関係(※1)が揃っているかわからない->PowerShell 2.0

※1 Excelは依存関係の1つと数える

**デフォルトの名無しさん** · 2018/08/25(土) 13:30:13.57

RDBとの連携　←　必須
dll作って呼ぶ　←　普通にやる
テキストファイルの読み書きをする　←　あんまりやらない

**デフォルトの名無しさん** · 2018/08/25(土) 18:46:09.73

>>99
呼吸することをわざわざ宣言するバカはいない。

なんでPowerShellバカばかり来るんだろう。

**デフォルトの名無しさん** · 2018/08/25(土) 18:49:03.73

実際、VBAじゃどうにもならないこともある。
なんで他言語自慢はVBAでも出来ることばかりなんだ?
他言語でもレベルの低い奴ばかり来てるんだろうな。

**デフォルトの名無しさん** · 2018/08/25(土) 19:21:39.09

>>115
呼吸みたいなこともできんので驚いたって話だよ

**デフォルトの名無しさん** · 2018/08/25(土) 19:38:40.64

自分から驚きにいってあえて驚いたと言いたがるアホw

**デフォルトの名無しさん** · 2018/08/25(土) 19:40:49.82

VBAの何が良いって、適当に書いたプログラムを他人に渡しても、受け取った人（IT系では無い一般事務員)がその場で治せることが一つのメリットだと思う。
Powershellみたいに一行に何でもかんでも押し込まれたら、読めるもんも読みたくないわ
ましてや電話越しにデバッグして貰うとかVBAか関数にしか無理

**デフォルトの名無しさん** · 2018/08/25(土) 19:48:19.41

>>119
別にパワーシェルやから一行に何でもおしこめる訳ちゃうわw
ワンライナーに童貞を奪われた厨房ってのは何時の時代も一定数おんねんw

**デフォルトの名無しさん** · 2018/08/25(土) 20:12:22.32

ワンライナーは人に渡すもんではなく、自分用だよ、きちんとps1ファイルに書くことも可能

**デフォルトの名無しさん** · 2018/08/25(土) 20:14:43.66

>>119
かつて無いほどアホくさいレス

**デフォルトの名無しさん** · 2018/08/25(土) 20:27:16.37

試しに同じ処理をVBAで書いてどっちがわかりやすいか、変更・拡張しやすいか、比べてみませんか
ハンデとしてワンライナーじゃなくても構いません
VBAユーザーの皆さんさあどうぞスマートなコードを書けるものならぜひ書いてみてください
もちろん尻尾巻いて逃げるのは構いませんがそんな情けない人はここには居ないと信じています

**デフォルトの名無しさん** · 2018/08/25(土) 20:34:55.96

>>123
>>79の話？ああ良いですよ書いてあげましょう

**デフォルトの名無しさん** · 2018/08/25(土) 20:35:18.16

VBAの全力をお見せしましょう

**デフォルトの名無しさん** · 2018/08/25(土) 20:36:24.71

>>125
その意気です
さあ書いてください

他の様子見してるチキンの皆さんも参加しても構いませんよ

**デフォルトの名無しさん** · 2018/08/25(土) 20:41:37.12

>>117
呼吸みたいなことをわざわざ書くとか驚きなんですけど w

**デフォルトの名無しさん** · 2018/08/25(土) 20:42:30.57

できました

Files = ReadCsvFiles("*.csv")
Data = ReadCalcPower(Files)
Sort Data, "desc"
ExportExcel Data

**デフォルトの名無しさん** · 2018/08/25(土) 20:44:48.11

>>127
例えば隣に座ってるおじさんが呼吸してなかったら驚くし声をかけるだろう？
ねえねえVBAくんさっきから息してないけど大丈夫？生きてる？
まあだいたいそういう感じ

**デフォルトの名無しさん** · 2018/08/25(土) 20:49:05.28

powershellは凄いぞ！ワンライナーで何でも掛ける！
って言ってる奴が出てきた時はまともなpowershellユーザーがちょっと可愛そうではあった

**デフォルトの名無しさん** · 2018/08/25(土) 20:50:11.46

>>128
Subも書けよww

**デフォルトの名無しさん** · 2018/08/25(土) 20:51:53.55

>>131
PowerShellと粒度を揃えましてん

**デフォルトの名無しさん** · 2018/08/25(土) 20:52:42.36

VBAの書き方がわからないおじさんに教えてあげましてん

**デフォルトの名無しさん** · 2018/08/25(土) 20:57:11.08

>>130
まともなパワーシェルユーザーなんか居らんわwバカかとんでもないバカだけやw

**デフォルトの名無しさん** · 2018/08/25(土) 20:57:11.62

>>128
素晴らしい
ReadCsvFiles、ReadCalcPower、Sortの実装が見えないけどバグかな？

**デフォルトの名無しさん** · 2018/08/25(土) 20:58:25.40

誰とは言わないけど負け犬敵前逃亡兵がきゃんきゃん吠えとるのw

**デフォルトの名無しさん** · 2018/08/25(土) 21:01:55.54

>>135
バグではないよVBAではこのように抽象化することで
コードをわかりやすく書くの
PowerShellでもExcelExportがどうなってるかは見えないよね
それと一緒

**デフォルトの名無しさん** · 2018/08/25(土) 21:07:45.78

検証できないから意味がない >>90は誰でも検証可能

**デフォルトの名無しさん** · 2018/08/25(土) 21:10:25.06

今までそーっとしといたけどVBAにソートないんだよね

**デフォルトの名無しさん** · 2018/08/25(土) 21:13:56.58

>>138
検証してやるから全部のソース出してよ
Export-Excelもそう、Sort-Objectもそう、それらのソースコードを
提出していただこうか、粒度を合わせるんだよ

**デフォルトの名無しさん** · 2018/08/25(土) 21:14:46.00

>>139
ソートはないよ、自分で作るなりネットから拾ってくるなりで

**デフォルトの名無しさん** · 2018/08/25(土) 21:15:13.16

粒度の違うものを比較しても仕方がない

**デフォルトの名無しさん** · 2018/08/25(土) 21:24:30.80

>>137
いやいや抽象化は構わないけど
中身がないとバグだよ

はいソース
https://github.com/PowerShell/PowerShell
https://github.com/dfinke/ImportExcel
キミは誠実な人だから惨めに言い訳して逃げないでVBAで実装してくれるよね

**デフォルトの名無しさん** · 2018/08/25(土) 21:26:10.63

ここ来るとVBAのおかげで飯が食えてる俺は先が無いなって思わされる

**デフォルトの名無しさん** · 2018/08/25(土) 21:30:20.04

>>143
長すぎて読む気にならない
無駄なものを貼るな

**デフォルトの名無しさん** · 2018/08/25(土) 21:38:17.09

>>145
あれれーキミも言い訳して逃げちゃう人だったんだ

**デフォルトの名無しさん** · 2018/08/25(土) 21:49:32.83

>>146
僕は一切言い訳をしないし逃げることもない
ずっとここにいる、君はなぜここに居る

**デフォルトの名無しさん** · 2018/08/25(土) 21:49:50.30

なぜPowerShellのソースコードを貼る

**デフォルトの名無しさん** · 2018/08/25(土) 21:54:36.91

>>147
>>137

**デフォルトの名無しさん** · 2018/08/25(土) 21:58:36.58

>>149
僕が言ってることには完全に筋が通っている
粒度を合わせることによってVBAとPowerShellの比較を可能にして
VBAのコーディング方法をPowerShellユーザに伝授した
もっと丁寧なお礼をいただいても良いと改めて読み返してそう思った

**デフォルトの名無しさん** · 2018/08/25(土) 22:18:30.20

>>150
えーつまりVBAのコーディング作法では
未定義の関数を呼び出してエラーが出るのを眺めるのが正義、ということですか
流石vbaerは言うことが一味違いますね

**デフォルトの名無しさん** · 2018/08/25(土) 22:19:12.23

>>151
誰もそんなこと言ってないですね
あなた誰ですか？

**デフォルトの名無しさん** · 2018/08/25(土) 22:22:37.73

というかことの起こりは

>>79

このレスだぞ
このレス自体はPowerShellとは無関係な純粋なVBAの質問だろ？

そのあとでPowerShellだとどうやるのと聞き返されたから答えたまで

ということで純粋なVBAの質問である>>79への解答を待ってます
VBAでは実現不可能でしたら解答しなくても結構です

**デフォルトの名無しさん** · 2018/08/25(土) 22:24:42.27

>>153
VBAで実現可能です
純粋なVBAの最終解答をお示しします

Files = ReadCsvFiles("*.csv")
Data = ReadCalcPower(Files)
Sort Data, "desc"
ExportExcel Data

**デフォルトの名無しさん** · 2018/08/25(土) 22:29:22.06

>>154
動きませんでした
嘘をつかれては困ります

**デフォルトの名無しさん** · 2018/08/25(土) 22:29:54.81

ワークシートの名前を変更するにはどうしますか？

VBAでどうやるのか聞き返されたら答えるまでですけど
PowerShellではどうやるのか教えてください

**デフォルトの名無しさん** · 2018/08/25(土) 22:30:42.72

>>155
だったらPowerShellのプログラムも僕の環境ではピクリともしません
それを嘘つきというならPowerShellの方が嘘つきです

**デフォルトの名無しさん** · 2018/08/25(土) 22:31:13.63

>>156
に答えてください

**デフォルトの名無しさん** · 2018/08/25(土) 22:38:12.10

>>156
$app = New-Object -ComObject Excel.Application
$book = $app.Workbooks.Open($targetFilePath)
$book.Worksheets($targetSheetIndex).Name = "NewName"
$book.Close($true)
$app.Quit()

こちらは答えましたよ
あなたもはぐらかさないで真面目に>>79に答えてください

**デフォルトの名無しさん** · 2018/08/25(土) 22:41:51.71

>>159
VBAではこうです
ActiveSheet.Name = "合計"
ワンライナーで一撃です

>>79に答えます
VBAではこう書きます
Files = ReadCsvFiles("*.csv")
Data = ReadCalcPower(Files)
Sort Data, "desc"
ExportExcel Data

**デフォルトの名無しさん** · 2018/08/25(土) 22:45:42.55

>>160
あなたのコードには致命的な欠陥があります
対象とするブックを手作業で開かなければならなりません
これでは自動化を検討する程度の数のブックを相手にした時に間違いなく腱鞘炎になってしまいます

>>79への解答は不適切です
このコードには未定義の関数・サブルーチンが含まれているため動作しません
関数・サブルーチン化するならその実装も解答に含めて下さい

**デフォルトの名無しさん** · 2018/08/25(土) 22:46:32.76

確かに、なんでもワンライナーで出来るかのような表現を使うよね、Powershellユーザー。

多分、そうは書いてない、思い込みだろうってレス着くと思うけど。

**デフォルトの名無しさん** · 2018/08/25(土) 22:51:17.33

PowerShellとCOMってGCの方式が違いますよね
一方は世代別GC、一方は参照カウント
GC方式の違うものを混ぜるとメモリリークしますよ
>>159はメモリリークしますよ

**デフォルトの名無しさん** · 2018/08/25(土) 22:51:56.89

>>159のソースはそのままで動くの？

**デフォルトの名無しさん** · 2018/08/25(土) 22:52:25.25

>>162
あなたの主張はデタラメです
パワーシェルはワンライナーであらゆる処理を書けるほど表現力が高く、基本ライブラリが充実していることは確かに事実ですが
だからと言ってなんでもワンライナーで書くわけではありません
パワーシェルのユーザーは
1つのコマンドで1つの仕事を上手くこなす
コマンドを組み合わせて大きな複雑な仕事をこなす
というシェルプログラミングの良い習慣をもちろん知っています
論より証拠ということで>>143のリンクをみてください

**デフォルトの名無しさん** · 2018/08/25(土) 22:53:00.08

>>163
しませんよ
リークするなら証拠を提示してMicrosoftに報告してください

**デフォルトの名無しさん** · 2018/08/25(土) 22:53:11.40

>>161
いま開いてるExcelのシート名変えるってことなら問題ないですよね
じゃあそれで、むしろそれで

現在開いてるExcelのシート名をPowerShellで変えるにはどうしますか？

**デフォルトの名無しさん** · 2018/08/25(土) 22:53:42.68

>>99 > 呼吸することを自慢する人間はいない
↓
>>129 > 例えば隣に座ってるおじさんが呼吸してなかったら驚くし声をかけるだろう？

こんな脈絡のないことを言い出してて驚くわ
まあ気味悪いから対面してたら放置するけど w

**デフォルトの名無しさん** · 2018/08/25(土) 22:55:26.08

>>166
マイクロソフトも認識してます
だから.NETにはReleaseComObjectという
COMのためのメソッドが用意されてます
あなたのコードにはメモリリークのバグが存在します、僕はあなたにそれを報告します

**デフォルトの名無しさん** · 2018/08/25(土) 22:59:43.30

>>167
[Runtime.Interopservices.Marshal]::GetActiveObject('Excel.Application').ActiveSheet.Name = "NewName"

逆に聞きますが、エクセルが起動していない時に、指定のブックの指定のシートの名前を変えるVBAコードは、どうやって書けばいいのですか？

**デフォルトの名無しさん** · 2018/08/25(土) 23:01:55.95

>>170
まずExcelを起動します
開発のボタンを押してマクロエディタを起動します
そしてワンライナーの一撃コードを実行します
これがVBAの正規の手順です

**デフォルトの名無しさん** · 2018/08/25(土) 23:03:45.08

[Runtime.Interopservices.Marshal]::GetActiveObject('Excel.Application').ActiveSheet.Name

これ暗記してるん？すごい

**デフォルトの名無しさん** · 2018/08/25(土) 23:04:21.09

メモリリークしてますけど

**デフォルトの名無しさん** · 2018/08/25(土) 23:04:53.64

便乗で聞きたいんだけど
powershellでVBAの定数はそのまま使えるの？定数をCOMか何かからロードしたりするの？
あと名前付き引数とかどう処理するの？

**デフォルトの名無しさん** · 2018/08/25(土) 23:05:39.78

>>169
ReleaseComObjectは速やかに参照カウントを減らすためのものです
それを実行しなくてもGCやプロセス終了時にリソースが解放され参照カウントも適切に処理されるので安心してください

明示的にReleaseComObjectを呼ばなければリークする、などという危険な状態を主力商品の1つである.NET上で放置するほどMicrosoftは怠惰ではありません

**デフォルトの名無しさん** · 2018/08/25(土) 23:06:53.30

>>169
思った通りのレスですねw

**デフォルトの名無しさん** · 2018/08/25(土) 23:07:44.56

>>171
それでは手間が多すぎます
おそらく手作業でシート名をクリックして名前を入力する方が早いでしょう

**デフォルトの名無しさん** · 2018/08/25(土) 23:09:52.00

>>173
証拠の提示をお願いします
メモリリークの場合最低でも次の3つは欲しいですね

再現性のあるメモリリークを起こすコード
メモリを測定するコード
あなたの環境で測定したデータを分析したレポート

**デフォルトの名無しさん** · 2018/08/25(土) 23:10:23.46

>>175
参照カウントじゃないから参照なくなってもGCが動くことが保証されないですよ
プロセスがすぐ終了するかも仕様次第ですし、博打プログラミングですよ

GCの方式が違うからこれは技術的にどうしようもないんですよ
怠惰ではないです、むしろマイクロソフトは頑張ってる方ですよ
実装者の知識と努力に期待せざるを得ないのは宿命です

**デフォルトの名無しさん** · 2018/08/25(土) 23:12:21.64

>>177
こう考えてください、VBAを書くときExcelは起動してるんです
マクロエディタも起動してるんです、手間なんて何もありません
手作業では大変なことを行おうとしてるさなかのシート名変更ということですね

**デフォルトの名無しさん** · 2018/08/25(土) 23:14:42.41

>>178
GC方式が違う、それが証拠です
PowerShellにデストラクタが存在しないことが
GC方式が違うことの証拠です
GC方式とソースコードからメモリリークは明らかです
明らかなものに調査はそれ以上の調査は必要ありません

**デフォルトの名無しさん** · 2018/08/25(土) 23:14:59.37

>>179
すぐには回収されないだけとリークするの間には深い溝があります
遅くともある時点までには解放されることがわかっているわけですから、博打でもなんでもありません
.NETにはそれをコントロールする術も用意されています

**デフォルトの名無しさん** · 2018/08/25(土) 23:17:12.93

>>182
コントロール術が用意されてるならそれを使ってコードを書いてくださいよ
解放されることはわかりませんよ、.NETでGCが行われることは保証されません
.NETにはデストラクタがないでしょう？それが証拠です

**デフォルトの名無しさん** · 2018/08/25(土) 23:19:11.39

>>180
いいえ
残念ですが起動していないことの方が多いでしょう
もし起動していたとしてもシート名を直接変える方がマシです

**デフォルトの名無しさん** · 2018/08/25(土) 23:20:33.06

excelのマクロの効率的な書き方について相談できるサイトってどこかにある？仕事の話なのでこういうところに公開することはできないので…

**デフォルトの名無しさん** · 2018/08/25(土) 23:22:33.22

>>181
支離滅裂で全く明らかではありません
GCでインスタンスが回収されると自動的に参照カウントが適切に処理されます
したがって何もせずともリークは起こりません
回収が少し遅れるだけです

**デフォルトの名無しさん** · 2018/08/25(土) 23:24:33.26

>>184
Excel VBAを実行するのにExcelファイルが開いてない？？
支離滅裂ですね。

**デフォルトの名無しさん** · 2018/08/25(土) 23:25:30.09

>>183
[GC]::Collect()

CLRではデストラクタではなくファイナライザがサポートされています
ご安心ください

**デフォルトの名無しさん** · 2018/08/25(土) 23:25:42.27

>>185
マイクロソフトのフォーラムとかどうだろ

Technet フォーラム
https://social.technet.microsoft.com/Forums/ja-jp/home

**デフォルトの名無しさん** · 2018/08/25(土) 23:26:47.14

>>188
ドトネトーは世代別GCなので1回実行しても回収される保証はないですよ

**デフォルトの名無しさん** · 2018/08/25(土) 23:29:32.44

>>187
あるブックのあるシート名を変えたいと思った時にエクセルが都合よく開いているとは限りません

**デフォルトの名無しさん** · 2018/08/25(土) 23:31:35.44

>>188

Object.Finalize メソッド (System)
https://msdn.microsoft.com/ja-jp/library/system.object.finalize(v=vs.110).aspx

| ガベージコレクションは非決定的であるため、ガベージコレクターが終了処理を実行すると正確にわかっていません。
| リソースを解放する、すぐにこともできますを実装する、 dispose パターンとIDisposableインターフェイスです。

マイクロソフトも半分支離滅裂ですがファイナライザの使用が非推奨なことが読み取れます
IDisposableインターフェースが用意されてるくらいです

**デフォルトの名無しさん** · 2018/08/25(土) 23:33:01.95

>>190
引数なしのCollectはすべてのジェネレーションのガベージコレクションを直ちに強制実行します

**デフォルトの名無しさん** · 2018/08/25(土) 23:34:23.56

>>193
勉強になります

**デフォルトの名無しさん** · 2018/08/25(土) 23:35:38.63

>>191
Excel VBAを実行するのだからExcel ファイルは開いてますよ。
指定のファイルが開いてないってことを言いたいの？
その場合の処理はあなたのPower shellのコードと大差ないけど。

**デフォルトの名無しさん** · 2018/08/25(土) 23:35:49.52

でもそれを呼ぶ前に全部のメモリ参照をなくす必要があります
それってできますか？ PowerShellの変数スコープは変態ですから
事実上不可能です

**デフォルトの名無しさん** · 2018/08/25(土) 23:40:52.15

>>192
MSDNの翻訳が酷いことは有名なのでそれは我慢しましょう

リソース解放の時期をコントロールしたいなら決定的なIDisposableを使ってください
決定的でなくても問題がないならIDisposableに頼る必要はありません

スクリプトの利用形態から考えるとプロセスの寿命は非常に短くなります
これはエクセルインスタンスが本当に必要なくなった瞬間とプロセスの終了が時間的にほとんど離れることがないということです
このような場合では決定的な解放にこだわらなくても問題にはなりません

**デフォルトの名無しさん** · 2018/08/25(土) 23:45:22.40

>>195
私の書いたコードでは指定のブックを開く必要がありません

**デフォルトの名無しさん** · 2018/08/25(土) 23:47:08.86

>>197
そうとも限らないと思います
スクリプトを使うということは手作業での作業が煩わしく
それを効率化したいという欲求があるためです
スクリプトを書くとき、その時は常に手作業を躊躇する程の事態が発生している
状況と考えるべきで、ある処理がメモリを使んで離さなくて別の処理が
完了できないという経験を僕は山ほど経験してきました
メモリ管理を甘く見ると痛い目を見ます痛い目を見ます

**デフォルトの名無しさん** · 2018/08/25(土) 23:47:54.93

ﾊﾟﾜｰ系池沼ｼｪﾙ

**デフォルトの名無しさん** · 2018/08/25(土) 23:52:33.06

>>198
パワーシェルのスクリプトを作成して
コマンドプロンプトを起動して
コマンドを入力する必要があるじゃないですか

その時間使ってExcelを起動しましょう
VBAなら一撃です

**デフォルトの名無しさん** · 2018/08/25(土) 23:54:08.14

>>196
処理を適切に構造化して変数のスコープを無闇に伸ばさなければ、自然と不要な変数の参照は辿れなくなります

そして先ほども書いたようにスクリプトはプロセス全体の寿命も短くなりやすいので
変数のスコープはそれほど問題にはなりません

どうしても変数をクリアしたいならClear-Variableというコマンドレットがあります
個人的に使う機会がないコマンドレットですがスコープとワイルドカードを指定してまとめて変数を消去でるそうです

**デフォルトの名無しさん** · 2018/08/25(土) 23:55:26.38

>>198
>>156
$app = New-Object -ComObject Excel.Application
$book = $app.Workbooks.Open($targetFilePath)
$book.Worksheets($targetSheetIndex).Name = "NewName"
$book.Close($true)
$app.Quit()

ファイル開いてるけど、頭おかしいの？

**デフォルトの名無しさん** · 2018/08/26(日) 00:02:52.04

>>199
シビアなリソース管理が必要ならその時に適切なコードを書けばいいでしょう
なにもすべてのスクリプトを怠惰に書けと強制しているわけではないのですから
ですがほとんどの日常作業でそこまでシビアなリソース管理が要求されることはありません
それとリソースの不足は非決定的なリソース解放よりも非効率的なアルゴリズムが原因で発生することが多いということは知っておいた方がいいでしょう

**デフォルトの名無しさん** · 2018/08/26(日) 00:05:13.99

>>201
あなたの書いたコードは名前を変えたいと思うたびにブックを開かなければなりません
シェルを1度起動してパラメータを変えるだけとは訳が違います

**デフォルトの名無しさん** · 2018/08/26(日) 00:05:54.18

>>203
開いているのはプログラムです
手作業で開くのとは全く意味合いが異なります