Excel VBA 質問スレ Part59

2019/02/09(土) 15:12:30.70

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

ExcelのVBAに関する質問スレです
コード書き込みや作成依頼もOK
※前スレ
Excel VBA 質問スレ Part58
https://mevius.5ch.net/test/read.cgi/tech/1542577644/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2019/03/07(木) 07:24:21.94

>>691
valueで配列コピペした後に、セルに対してそれぞれ書式設定を手動もしくはマクロですれば？
書式は列ごとくらいは揃ってると思うし。
それもバラバラってことだと、そもそも集計の仕方が悪過ぎる。

2019/03/07(木) 07:28:16.03

>>674 >>678
ありがとうございます！
意図するようになりました。
-1で減らしていく発想は本当になかったのでいい勉強になりました。
このたびは本当にありかございました。

2019/03/07(木) 07:44:13.43

>>696
684じゃないけど、複雑に関数組んだりとか遅い関数が大量に入っててかつデータ数がエクセル上限近くで再計算に時間がかかるとか、あとセル上で反復計算やソルバー使ってたりするとある。
ただ684は書式がバラバラなセルを扱ってる時点で、複雑な計算をしてるとは思えないけど。

2019/03/07(木) 07:52:53.03

>>699
>>675をもう一度見て来いよ。　これだぞ。そんなややこしいことしている話ではないと思うが

>表示形式が混在したセルを見た目通りのまま表示形式が文字列の別のセルにコピーするいい方法ありませんか

**675** (ｽﾌｯ Sd32-tsl5) · 2019/03/07(木) 08:38:04.86

再描画等定番の部分は止めています
セル数は100万ぐらい、列数、行数分回してTextプロパティを1セルずつ配列に入れる処理だけです
シートへの貼り付け処理ではなくこの取得部分に時間がかかります
同じ回数回す②や、Format関数、worksheetfunction.textを使った場合その半分以下の時間ですが望みの結果を得る方法はわかりませんでした…

2019/03/07(木) 10:57:17.39

コピーした後NumberFormatで整えればええんちゃうん？
Dim buf() As Variant
buf = Range("A1:A3").Value
Range("B1:B3").Formula = buf
Range("b1").NumberFormat = "yyyy/m/d"
Range("b2").NumberFormat = "h:mm"
Range("b3").NumberFormat = "[$\-ja-JP]#,##0;-[$\-ja-JP]#,##0"

データが多すぎて無理？

2019/03/07(木) 10:58:23.63

アー、見た目が同じまま、「文字列」なのか・・・
すんません無視してください

2019/03/07(木) 11:39:04.19

>>675
A1:A3をコピーしてメモ帳とかに貼り付け
全選択してコピーしてB1:B3に貼り付けでできた
VBAだけで完結させる方法は知らん

2019/03/07(木) 12:41:45.56

勘違いしてる奴が多いが、自動計算を止めたり描画を止めるのは初心者が速度アップのためにやる方法で、>>675のように速度アップの為に考えて組まれている場合には効果が無い。

上級者はこういう場合に描画止めたりしないよ。
考えずに組んで面倒くさい場合にやる奴はいるかもしれんけど。

**675** (ｽﾌｯ Sd32-tsl5) · 2019/03/07(木) 12:42:12.66

>>702
あとからNumberformatを適用させるんでなく配列に入れる時点で適用させる手を考えたんですが、
適用させるのにworksheetfunction.textを使うと書式に「マイナス値は[赤]」みたいな色設定があるとなぜか1004エラーが出るし、Format関数使うと表示形式が標準の時なぜか値が「標準」という文字列になってしまいます
速度的にはtextプロパティ使うよりずっと速いんですが…もう訳がわからない

2019/03/07(木) 12:46:54.74

>>675
他に方法があるか探る時間が無いので何とも言えんが、DB処理にするか、マルチプロセスで上手いことすれば早くなると思う。

2019/03/07(木) 12:50:28.91

よく考えたらDB処理は駄目な気がする。
表示部分を扱え無さそうだ。

2019/03/07(木) 18:02:24.90

メモ帳にコピペすると書式が全部消えて見た目通りの文字列になる
メモ帳アプリの実体はエディットコントロールそのものだから、ユーザーフォームにエディットコントロールを貼っただけの作業場所を作って、そこ経由でコピペしてみたら？

2019/03/07(木) 18:03:18.10

UserForm1にTextBox1とCommandButton1、TextBox2とCommandButton2の計4つが配置され
UserForm2には入力フォームが配置されています。

CommandButton1からUserForm2を呼び出した時は、TextBox1に記入
CommandButton2からUserForm2を呼び出した時は、TextBox2に記入

させるには、どうすれば良いですか？

2019/03/07(木) 18:34:04.34

>>709
これ、本当?
だったらクリップボード弄って高速化できるかもしれない。

2019/03/07(木) 18:34:43.55

複雑な処理でデータ量が多いなら遅くても仕方ないんじゃね？
どうせエクセルだし、専門職じゃないし、大した会社じゃないし、給料安いし

2019/03/07(木) 19:03:35.19

>>710
やり方はいくつもある
一番簡単な方法を書くと、

Userform1側の各ボタンのクリックイベント内に、任意のセルや標準モジュール上のPublic変数等にコマンドボタンのオブジェクト名をコピーする処理を書く(Me.ActiveControl.Nameでフォーム上でフォーカスされているコントロールオブジェクトの名前を取れるのでこれを使う)

Userform2側のイベントコードではそのコピーされたボタン名を読み取って書き込み先のテキストボックスを判定するようにする

2019/03/07(木) 19:11:06.28

>>710
コマンドボタンのクリックイベントプロシージャで、グローバル変数に呼び出したボタン番号を格納→ユーザーフォーム2のコンストラクタでグローバル変数で分岐させる方法

もしくはコマンドボタンのクリックイベントプロシージャでユーザーフォーム2のマルチページコントロールのプロパティを変更する（value=1,2）方法もある

**675** (ﾜｯﾁｮｲ a37c-DZHv) · 2019/03/07(木) 21:34:32.55

セル範囲をコピーしてクリップボードから直接二次元配列に入れるようにしたら何十秒もかかってたのが0.5秒になりました
ただ、クリップボードから切り出す時にうっかりセルの値に手を加えてしまわないかが心配です
単純にVbCrLfで行を区切って、VbTabで列を区切ってるんですがそれで問題ないんでしょうか？

2019/03/07(木) 22:48:37.99

>>715
セル内改行を使ってなければそれで大丈夫

2019/03/08(金) 00:03:05.83

>>716
セル内改行入れてみたら…またこんな落とし穴が…

2019/03/08(金) 02:12:12.40

>>713
>>714
プロジェクトが大きくなるにつれグローバル変数は神経を使うので
極力さけたかったのですが
Form1.ActiveControl.Name、でいけそうですね

2019/03/08(金) 03:08:04.26

システムの大規模化が想定されるならユーザーフォームでユーザーフォームを呼び出すのは危険w
ユーザーフォーム間の依存性を高めてしまうw
ここはユーザーフォームを呼び出すクラスを作った方がいいw
クラスを介して情報を渡せば安全だし再利用性も高まるw

2019/03/08(金) 08:00:14.88

やっぱりuserformからuserform呼ぶのってよくないのか
こういうのってクラスモジュール使えるんだろうなって思ってたんだけど
余り使ったことなかたんで、ちゃんと勉強してみよう
参考書ぽちってきたわ
JavaとかC#を多少触ってきたからオブジェクト指向の概念は分かってるんだけど
VBAでの効果的な使い方をマスターしたいわ

2019/03/08(金) 08:01:46.46

引数付きコンストラクタすら簡単に実装できない言語で呼び出し用クラス作る方がきついと感じてしまうね、個人的には

2019/03/08(金) 08:08:56.71

普通のコンストラクタには引数渡せないんだ
まぁその辺の限界も含めて一度勉強しておいたほうがいいとは思ってる
できることと出来ないことを知った上で、クラスを使う選択肢を持つことができればいいかなって

2019/03/08(金) 08:15:50.67

VBAでクラスとか言ってるのはたいてい知ったかだからスルーしていい
VB.NETとかC#知ってたらストレスしかたまらん

2019/03/08(金) 08:23:55.15

そもそもVBAにクラスが欲しくなるような規模の要件を押し付けている時点で業務設計が破綻してる

2019/03/08(金) 08:24:18.53

こういう場合にクラス使うの?
何か違うと思うんだが。

VBAでも見た瞬間にクラス使おうと思う場合もあるんだが、そういうことは少ないな。>>323のような話なら見た瞬間にクラスだなと思うんだけどね。

2019/03/08(金) 08:43:43.11

>>725
ワークシート上でデータが常に単なる二次元の表として見えているために、
その行をエンティティとして見るような発想になりにくいんだろうね
別にそれが悪いとは思わないが

2019/03/08(金) 08:55:03.19

逆にいうと、ワークシート上で人間が無理なく扱えるようなデータ構造にならざるを得ないから、
生え抜きのVBerが作りがちな酷いDB設計になりにくい
そういう良い意味でデータ構造に無理が利かないので、クラスでデータ構造を抽象化したくなるケースが少ないのだと思われる

2019/03/08(金) 12:25:06.22

DBとして扱うならクラス使うことも考えるよ。
でも、DBとして扱うことも多くない。
DBならAccessにしちまうんで。

2019/03/08(金) 16:46:49.91

いまAccessを使う理由って何？
無料版のSQL Server のスペックの方が上だろう。
移行が大変だから？

2019/03/08(金) 16:53:49.99

エンジンだけで比べてる頭の不自由な人かな？

2019/03/08(金) 16:53:54.67

フォーム中心のまともなデータベースアプリが比較的簡単に作れるという点では意味がある
まあ今ならPowerApps使えばいいと思うけど

2019/03/08(金) 17:59:29.39

PowerApps使うならPowerShellかJScript使わないとな
まぁVBAは要らんわ

2019/03/08(金) 18:55:16.76

???
会社のPCに既にAccessがインストールされているのにもかかわらず、
Excelで扱うような程度のものをDBとして扱いたい時に、SQL Serverインストールはじめちゃう人?

全てにおいてセンスねーわ。

2019/03/08(金) 18:56:25.33

まだSQLiteの方が理解出来るわ。

2019/03/08(金) 19:18:32.09

>>733
正直君の意見はよくわからん
Management Studioすごく便利だよ
それにExcel からADOやODBCでつつく際のIFは大して変わらないんだからSQL Serverの方がパフォーマンスいいじゃん

2019/03/08(金) 19:24:33.31

うちの会社そういうの入れる時はそれを使う理由説明して了解得るのに手間がかかる

2019/03/08(金) 19:46:50.70

まあ普通はセキュリティ部門にリクエストして審査通らんと入れるのは無理だわな
VBAも原則禁止だから毎回例外申請してるわ

2019/03/08(金) 21:38:31.98

環境申請が必要な業務を未経験者にさせるほどうちの会社はブラックじゃない

2019/03/08(金) 21:38:33.69

>>735
馬鹿はエンジンしか見ていない

2019/03/08(金) 22:23:14.58

具体的な事を言えよ

2019/03/08(金) 23:50:58.19

>>740
馬鹿には理解できんのか？

2019/03/09(土) 02:13:50.44

会社がoffice365に切り替わってAccess使えるようになった俺歓喜

2019/03/09(土) 02:15:54.88

accessはスレチ

2019/03/09(土) 04:02:18.85

accessって開発続いてるの？
Excelを強化してAccessを見放すように思えてしょうがない

2019/03/09(土) 04:12:29.83

accessはウンコです

2019/03/09(土) 07:26:22.26

Acccessとか。　いつの時代の遺品だよって感じだな
使いにくかったしなあ

2019/03/09(土) 07:48:05.33

>>744
>>731も書いてるけどExcelとAccessって用途が違うから当面なくならないと思うよ

2019/03/09(土) 08:34:58.65

SQLとOracleとAccess使うと書き方混乱する

2019/03/09(土) 09:22:46.51

シート上に複数のテキストボックスを配置して、
KeyDownイベント + vbKeyRightとかvbKeyTabで、
テキストボックス間を移動出来るようにすると、
カーソルがたまに見えなくなるんだけど、回避策ない?
見えないだけで、存在はしているので、
文字は打てるんだけど、文字まで透明になっちゃう。
テキストボックスを何回か適当にクリックすると、
突然見えるようになる。

2019/03/09(土) 09:24:00.36

↑あと、わざわざ画面更新を止めたりはしていない。

2019/03/09(土) 09:29:10.33

↑あ、別のPCで開いたら再現しなくなった。
もしかして、グラフィックボードの問題?

2019/03/09(土) 10:19:05.53

>>751
ボードと言ってるのはたぶんドライバのことだと思うけど、その可能性はあるよね。
いくつかバージョン違いを落としてきて試してみればいい。
とりあえずは、各メジャーバージョンが上がったばかりのは除いて、それぞれ最終リビジョンのを集めてきてかな

2019/03/09(土) 21:56:21.30

excel vbaとaccess vba
どちらの方が実用的ですか？

2019/03/09(土) 22:00:31.82

>>753
目糞鼻糞
今時ローカルで完結する業務要件なんかほとんどない

2019/03/09(土) 22:03:03.09

両方できて当たり前ですか？

2019/03/09(土) 22:06:43.06

触り始めればすぐ覚えるよ
触る機会がexcelのほうが多いってだけ

2019/03/09(土) 22:20:16.59

>>755
Excelだけでいいよ
今時AccessやるくらいならSalesforceでも覚えなさい

2019/03/09(土) 22:33:56.74

Accessに親でも殺されたのか？ w

2019/03/09(土) 22:36:15.94

>>755
超小規模ならExcel
テーブルの規模が大きくなってくるとAccess
Accessの何がいいかって言うとオレはレポートだと思ってる。あれを使いたいがために、オレはdbアプリ（フロントエンド）はAccess一択。
テーブルの規模がさらに大きくなってきたら、テーブルだけをoracle、SQLServerなりに移行。
そもそもAccessは大規模用ではないが、わかって開発すれば大規模用に寄せていくことはできる。

2019/03/09(土) 22:42:40.73

>>758
シンプルに、需要がない

2019/03/09(土) 22:43:14.91

>>759
Access一択は語弊があるけど、Accessだけで完結できるならAccess押し。
あとは顧客要望で、webなりc#なり様々

2019/03/09(土) 22:52:20.46

>>760
需要の無いものをMSがわざわざ開発して売ってるのかw
無職の妄想乙

2019/03/09(土) 23:38:00.61

>>762
実際ほとんど放置されてるでしょ
そもそもAccessってノンプログラミングで専用アプリ風のDBアプリが作れるのがメリットなのであって、そこは全く否定するつもりはないけど
プログラミングするんなら他にもっと優れた選択肢はいくらでもあるよ

2019/03/09(土) 23:47:17.35

With Access ってやりたくなってきたな

2019/03/10(日) 00:26:33.47

中小企業は普通にエクセル・アクセス
使える人間が多いのが最大のメリット。事務員だけでも割とどうにかなる

エクセルvbaは死ぬほど使う
アクセスはvbaじゃなくSQLを覚えたほうが良い
でもSQL覚えるのって結構たいへんなんだよよねぇ

2019/03/10(日) 00:34:07.81

とりあえずVBAはどっちでも同じだから、あとはどういう環境を用意されることが多いかと考えると圧倒的にExcelに縛られることが多いので実用で考えるとExcelだろうか
Accessでやる方が楽な時でもExcelでやらされることが多いし

2019/03/10(日) 00:37:17.38

Accessは大抵前任者なりシステムなりが作っている場合が多いから、ほとんど触る事が無い
エクセルは事ある毎に0から作ったり改修する事多いからvbaはめっちゃ役に経つ

2019/03/10(日) 00:45:32.25

素人が作って不正統計したりするのもexcel

2019/03/10(日) 00:54:56.33

>>765
複雑になってくるとSQL知識は必要になるけど、クエリーデザイナ（QBEグリッド？）でほとんどできてしまう。
昔oracleでSQLゴリゴリ書いてたあとAccessのクエリーデザイナ見て「これ考えたやつ天才やな」とマジで思った。
選択も更新も削除も書けて、テーブル連結も表現できて、革命やなと。

2019/03/10(日) 01:10:02.43

accessで帳票画面作りが便利過ぎて
Excelにもレポートつけて欲しい
方眼紙神Excel化しまくり

2019/03/10(日) 04:21:41.33

>>763
お前がAccess知らんだけだろw

2019/03/10(日) 07:28:22.90

>>771
そもそも今時ローカル限定のDBなんてほとんど役に立たなくね？
ちなみに、https://support.office.com/ja-jp/article/ビデオ-access-web-アプリを作成する-10855ec0-3a12-4e6c-a67c-c88267f00a3c
> 重要 Microsoft では、SharePoint で Access Web App を作成および使用することはお勧めしなくなりました。代わりに、Microsoft PowerApps を使用して、Web およびモバイルデバイス用にコードなしのビジネスソリューションを作成することを検討してください。

だそうだよ

2019/03/10(日) 08:09:35.64

Salesforceて。
クエリの自由度がAccess以下じゃん。

2019/03/10(日) 08:13:57.05

>>773
仮にそうだとしてもAccessより圧倒的にスキルの需要が高いのは事実だよね
それは何故だと考える？

2019/03/10(日) 08:46:12.12

>>772
まじでAccessに親でも殺されたのかよw
必死にググって探してきたんだろうけど見てて恥ずかしいぞ

2019/03/10(日) 08:48:28.53

>>772
ローカル？
Accesswebアプリ？
だから、知らないやつは黙っとけと。
自分の周りで需要がないから、どこもそうだとは限らないって考えられないのか？
MSが推奨してても、そうならなかったこともあるだろうに（いちいち書かない）。

2019/03/10(日) 09:03:35.58

>>774
sfは使ってる側だが、Accessと比べてる意味がわからん。
それぞれメリットデメリットがあって、顧客の要望にどちらがよりふさわしいかだぞ。
Accessのときもあるし、そうでないときもある
office365が広がって、Accessで作るメリットは開発側も、アプリ導入側も確実に増えてきた。
例えば、visualstudioで作るなら開発側は買わないといけない（小規模会社以外は）
これだけ書いてわからないとしても、スレ違いもあるからこれ以上議論しない。Accessスレでも、くだらないから議論しない

2019/03/10(日) 09:43:54.35

ここは顧客のためにアプリ開発してるような人が来るスレじゃない、というのが前提にあるんじゃないの？
だから話がずれてしまう

2019/03/10(日) 10:10:19.51

個人商店で売上管理する程度か、ソフト会社でシステム管理任されてるかでは違いすぎるわな

2019/03/10(日) 10:21:42.56

顧客の要望笑さんのように目の前の要件だけ片付けてトンズラできる立場なのか、
将来も含めて面倒見ないと行けない立場なのかでも全然違うわな
後者ならさすがにAccessは正当化できないわ

2019/03/10(日) 10:22:42.48

スキルレベルの話というより、制約条件が自分要因なのか顧客要因なのかが大きい。
こんな場所で顧客要因の話なんか相応しくないだろ、ってことだ。

2019/03/10(日) 10:42:00.95

とにかく安く作れと命令されればこうもなろう！

2019/03/10(日) 10:45:41.83

winformやwpfがaccessより優れていればよかったんだがな

2019/03/10(日) 11:17:38.37

>>783
分かる。なんか色々解決した気がする
Silverlightも死産だった

2019/03/10(日) 11:28:51.41

>>774
そりゃググればいくらでも情報出てくるAccessとは比較にならんからな。

2019/03/10(日) 11:34:33.33

えっと、、、ここExcel VBAのスレですよね？

2019/03/10(日) 11:44:50.15

馬鹿はAccessのエンジン部分だけしか見ていない

2019/03/10(日) 12:00:46.26

どうせくだらないオレオレ都合を一般化してるんだろ

2019/03/10(日) 13:42:15.79

Access VBAは提供機能の環境結合度がExcel VBA以上に強いイメージを持ってるんだけど、Office365になってもバージョンアップによる互換性の問題は変わらない感じ？

2019/03/10(日) 15:38:12.98

GUIをExcel、データストアをAccessとするアプリをVBAで作るのが最強ってことですね

2019/03/10(日) 16:10:54.47

>>789
提供機能の環境結合度が何を言ってるかわからないが、昔作ったやつの改造質問が時々来て、軽く動かす範囲において互換性に問題があったことはない。
互換性問題でお客様から問い合わせ来たこともない。mdbの話し。

>>790
違います（indeed風w）
それぞれで無理なく完結できるならわざわざ分けない。そもそも「GUIをExcel」とするほどの優位はない。
データストア（テーブル）をシートでゴニョゴニョできる範囲ならExcelでやってもいい。デカくなるとAccess。

最近経験したのは、Accessのグラフが昔のママだったので、新しいグラフを使うためにExcelに結果出力することにした
（ながっ。Accessスレ過疎ってるけど、そっちで書いたとここに書けば何人か見に行ってくれると思う）

2019/03/10(日) 16:46:27.59

Excelでも
VBAでも
質問スレでもない
でもどうせ平日は質問もないし、土日はこういう流れokみたいにしてもいいんじゃないかな

2019/03/10(日) 17:36:22.03

どうでも良いけどセンスね―奴が多いな。

Salesforceってw
まず、会社で自分が使う環境になってからの話だろうに。
AccessやExcelと同列で語るとは笑わせる。
SQLサーバーも一緒。

Accessは単体で完結する使われ方も有るけどフロントエンドで使われる場合もある。
で、どちらの場合もSQLサーバーとは比較の対象にはならない。

俺はトヨタとかホンダとかと同じ知名度の会社で働いてるが普通にAccess使ってる。
というか、大きな所は結局いろんなツール使ってる。

2019/03/10(日) 17:53:03.67

我慢できず煽りと自慢を入れちゃう辺りがかわいい

2019/03/10(日) 18:14:41.27

知名度で比較してもその中には昭和みたいなやり方の企業は山程あるんだが

2019/03/10(日) 18:19:33.93

>>795
あるかもね。
うちの会社は違うけど。