[ 初めての方へ | 一覧(最新更新順) | 全文検索 | 過去ログ ]
『Public変数、変数が定義されていませんとエラー』（あや）
EXCEL2003 XP
いつもお世話になっております。
Sheet1に ’-------------------- Public a As Integer
Private Sub Cmd1_Click() a = 10 Call Subテスト End Sub ’--------------------
標準モジュールのModule1に
’--------------------
Public Sub Subテスト
a=a+1 ☆
end sub
’--------------------
としています。
Cmd1を押すと ☆のところで止まって 「変数が定義されていません」とエラーメッセージが出ます。
ホームページを見て調べてみたところ 「Public」で宣言する変数は、 プロジェクト内の全ての場所から参照することができる。 と書いてあるので、使えるのでは？と思っているのですが…
現状動いていないので、 なにか違った理解をしているのかなぁ…
ご助言いただければ助かります。
Public a As Integer は 標準モジュールの方で記載してみてください。 (Mook)
先に読み込むほうがSheet1なので
流れ的に先に変数を読み込ませたほうが良いのかと思っていました。
（あや）
一応、普通はPublic変数は標準モジュールに宣言しますが 上のままでも、標準モジュール側で
Public Sub Subテスト()
Sheet1.a = Sheet1.a + 1
End Sub
とする事で使う事は出来ます。 あまりそんな事はしませんけどね （ｍｏｍｏ）
解決後ですが、
Sheet1に Public a As Integer と宣言したことに意味があるならば、動かないから という理由で 標準モジュールに移動するのは疑問を感じます。
Sheet1のモジュールに
Private a As Integer Private Sub Cmd1_Click() a = 10 a = fSubテスト(a) End Sub
’--------------------
Function fSubテスト(ByVal Intvalue As Integer) As Integer
fSubテスト = Intvalue + 1
End Function
プログラムの評価尺度に強度と結合度というのがありますから、 一度調べてみてください。 結合度という尺度を弱くする方がよいと唱えている設計書があります。
そのためには、データ渡しをパラメータで行うことがよい
と私は、教わった記憶があります。
ichinose
大域変数の取り扱いに関しては、プログラマであればなんらかの一家言はあると思います が、一般ユーザレベルに求める話でもないような気もします。
標準モジュールに持っていってのは、「動かないから」という現象的な理由ではなく シートモジュールのデータスコープはシート内だけに限定されるからという理由ですね。
まぁ、ただこの辺りは全体で使う宣言は標準モジュールにというように覚えておけば 良い話ではないでしょうか。
>結合度という尺度を弱くする方がよいと唱えている設計書があります。 と同意なことですが、 大域変数ではなく引数にした方が良いメリットは、変数をローカルスタックに持つこと によってグローバル変数を使う様々な制限から開放されることが大きいこともあるでしょうか。 再帰関数や相互呼び出しなどはこの端的な例ですね。 (Mook)
>データ渡しをパラメータで行うことがよい も >グローバル変数を使う様々な制限 これも結構大切だな〜なんて思います。
ichinoseさんもMookさんも素晴らしい。(^^)
（ｍｏｍｏ）@一般ユーザー
>一般ユーザレベルに求める話でもないような気もします。 では、この規定が私とは違います。プログラミングをするは、一般ユーザーと違うと いう認識です。
>シートモジュールのデータスコープはシート内だけに限定されるからという理由ですね。 シートモジュールのPublic変数は、シート内限定されるわけではないですよね 現にｍｏｍｏさんの記述のSheet1.a で外からも参照はできますからねえ オブジェクトモジュールのPublic宣言は、プロパティの簡易版ですから、 当然、こういう使用方法はあると思いますよ！！ 特定のシートオブジェクトに独自のプロパティを追加するのと同じです。 ですから、変数をシートモジュールに宣言した事に意味があるならば・・・、 申し上げました。 プロパティというワードは知らなくても特定シートに関連のある変数だから シートモジュールに宣言した という発想のある方はいますからね！！
>宣言は標準モジュールにというように覚えておけば >良い話ではないでしょうか。 知識としては、良いと思います。が、私は，基本的にPublic変数は、使わない方針で プログラミングするべきという立場から発言をしています。 (特に標準モジュールのそれです）。
>変数をローカルスタックに持つこと >によってグローバル変数を使う様々な制限から開放される プロシジャー間のデータ渡しでこれが推奨されるのは、↑これも含んだ意味での 結合度を弱くするという表現を複合設計法で言っているのだと思います。 (他にもメンテしやすいということもあります） この事は、私もプログラミングを始めた頃に散々言われたことだったので、ここでも 参考になるかなあと思い、記述しています。
ichinose
>オブジェクトモジュールのPublic宣言は、プロパティの簡易版 なるほど、解釈としてとってもわかりやすいですね^^
プログラミングは私は学んだ事が無いので スタンスは一般素人に近いと思いますが Publicやモジュールレベルもほとんど使わないですね。 再起Procで無意味にByRefで渡すような事がある時に使う程度でしょうか。
いつも勉強になります。 ありがとうございます。 #あやさんお邪魔してます。 （ｍｏｍｏ）
オブジェクト指向を理解されていれば、Sheet1.a という書き方こそが Sheet モジュール（オブジェクト）のスコープに起因することだとお分かりだと 思いますが。
他にもいろいろと気になる部分はありますが、揚げ足取りや不毛なプログラム論争は 忌避するところですので、以降この件に関するコメントは失礼します。 (Mook)
プログラミング技法に関する意見交換が不毛なのではなく、これを不毛にしてしまうのは、 投稿する人間の責任だと思います。つまり、Mookさんに不毛だと感じさせてしまったのは まぎれなく私に原因があるのでしょう！！
このPublic変数に関して私が投稿するのは、これが初めてではありません。 何度も投稿したような記憶があるのですが、年のせいで覚えているのは・・・、
GOTO文やPublic変数のというのは、機能は比較的容易に理解できます。が、 これを使ってわかりやすいコードを書くとなると、相当の経験を要する非常に難しい ステートメントだと思っています。
これをプログラミングを始めて間もない方が簡単だからって乱用すれば わかりにくいコードにきっとなる という事を危惧しています。
良い例として、上記リンクスレッドでも記述していますが、
>処理コードは、シートモジュールとユーザーフォームに記述されていて、ユーザーフォーム内で >クリックされたボタンの種類を表す変数が処理とは関係ない標準モジュールに宣言されている。 >こういうコードにしてしまうとご自分で作っても時間たってコードを読み返すと、 >何でいきなりこの変数？？？ ってことに成りがちなんです、私の経験上・・・。
こういうことは、プログラミングのやり始めが肝心です。
構造化プログラミングでは、これらを使わないことを推奨しています。 構造化プログラミングが万能だとは思いませんが、 プログラミングを始めて間もない方なら、まずはこの手法に従った方が 無難だと思うので、こういう投稿をしてきました。 Goto文やPublic変数を使ってすっきりしたコードを書くのは、その後で検討しても遅くはない という考え方です。
こんな思いから、今回の投稿に至りました。
ichinose
一点だけ。
ichinose さんの発言の内容だけが理由ではありません。 プログラミング論はある意味 宗教論のようなところがあるので、各自が各々の主張を してもお互いが合意に達することはめったになく、そのためきつい表現かもしれませんが、 不毛と書きました。
まぁ、どのような発言をするのも各自の自由ですし、各自が自身の信念に基づいて発言 すればよいと思います。 ですけれども、私は好みませんということでご了承ください。 (Mook)
>プログラミング論はある意味 宗教論のようなところがある プログラムを作成するにあたり、どこに軸をおいて作成するか (わかりやすさ、拡張性、再利用可能等）があってのことですから、 そういう側面は認めざるを得ませんね！！ が、技術を語る場面で「宗教論のような」というワードは、しばしばそのテーマを 軽く侮蔑した印象を与えます。 これも議論の仕方によって、技術の話の域で論じることは可能だと思っています。
>合意に達することはめったになく 結論が出ないから、不毛だということはないと思います。 結論が出なくともプログラミングを始めて間もない方にとって、 そのやり取りが有意義に感じてもらえるような意見交換は、情報として必要ですし 有意義と感じてもらえれば、いつの日かその意見交換に参加してもらえる日もきます。
他にもその意見交換から派生するテーマとは直接関係のない情報も有用なものもありますよね？
又、意見を記述した当事者にとっても、その時は結論が出なくても 時間置いて、相手の意見を読み返せば、頷ける箇所や、やっぱりこれは？？ という箇所が明確になり、相手の意見のこの部分を受け入れると 今より良い指針が発見できる なんてことがあるかもしれません。 仮にここまでに至らなくても意見交換の記録を残すことで 相手の意見を改めて読み返すことでき、何かを感じることはできます。
このような意見交換の場に出来るか否か ということも意見を記述する人しだいだと思います。 揚げ足とりの泥試合のようなスレッドにしたら、勿体無いことです。
過去にこれと同様結論に至らないスレッドはありました。
Set xx=nothing の是非に関する問題
Vbprojectの使用方法に関する問題
いずれも明確な結論等でていませんが、ここに意見を記述したこと、 違う意見が聞けたこと、有意義なものだと思っています。
今でも時間があるときに読み返したりすることがありますよ
>私は好みません という事ですから、仕方ありません。 もう少しご意見を伺いたかったのですが・・・。
ichinose
>Set xx=nothing の是非に関する問題 >Vbprojectの使用方法に関する問題 そして本スレッド。
全部拝見していますが 無知な私にはとても有意義です^^（スレ主さんが居ませんが） 結論はそれぞれで良いとも思ってます。 それがコードを書く人の個性になりますから。 全員が同じコードの書き方しかできない言語なんてつまらないですし。 いろんな方言の地域があって、どこに住むかは自由。 でも、その方言はどいういう意味なの？なんて会話が弾むのも一興ですよね
いつも楽しく拝見しています。
と、書き終えようと思いましたが >もう少しご意見を伺いたかったのですが・・・。 というichinoseさんのご意向がありますので、私の考え方は
通常Public変数は使いません。 それは、ichinoseさんが仰るようなプログラマとしての考え方や構造化とか （以前のスレにあった構造化プログラミングのリンク先も読ませて頂きました） Mookさんの仰るオブジェクト指向的な高度な理論や信念の部分ではなく 単に必要性をあまり感じないというだけの単純な理由です。 無くてもできる。であれば特に使う必要も無い。 でも、使い方を知る事で、使わなければならない場面や 使った方が有意義である場合に使う事も出来る。 無知ならではでしょうか？楽しくコードを書いてます。
（ｍｏｍｏ）@方言強し
せっかくの投稿に返信が遅れました。 >通常Public変数は使いません。 >単に必要性をあまり感じないというだけの単純な理由です。 なるほど・・・。 書物を読まずとも、 構造化プログラミングの概念がが自然に身に付いているのかも知れませんねえ。
>全員が同じコードの書き方しかできない言語なんてつまらないですし。 ただ、プログラミング技法ってのは↑この考え方と逆の観点から生まれてきたのでは？ と思います。細かい釘の打ち方の違いはあっても、大まかな骨格は、誰が作っても 同じようにしたい を目指している。 そうすると、他人が書いたコードをメンテする時など 時間の短縮が望まれます。同じ仕様に対し、類似した骨格を発想できれば、 そのコードの解釈は、比較的容易になり、引継ぎが楽になります。
Public変数に関して
以前にも構造化プログラミングを作成する手法の一つとして、 複合設計法をご紹介したことがあります。 http://www.netlaputa.ne.jp/~hijk/study/pe/program.htm#A03
↑ここで結合度のことを簡易的に記述しています。
http://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html#3_1
ここで、もう少し詳しく説明しています。 結合度を弱くするためには、データ結合（パラメータ渡し）が良いとされ、
広域変数（Public変数）を使用したデータ共有は、 外部結合とか共通結合と呼ばれ避けるべき方法として紹介されています。
そして、このようなデータを使いたくなった時は、 凝集度（プログラム強度）が情報的凝集度 になるように作成することを 考えなさい と言っています。
そして、この情報的凝集度のモジュールこそVBAでいうクラスモジュールです。 カプセル化です。オブジェクト指向です。
よって、私の言っていることとMookさんの言っていることは、全く違っていることを 言っているわけではないと思います。 というか、私がここに記述したようなことは、たぶんMookさんは、ご存知なのでしょうねえ。
じゃあ相違点は？？ 結局のところ、 >一般ユーザレベルに求める話でもないような気もします。 >では、この規定が私とは違います。
ここだけなのでは と思います。
ichinose
おはようございます。この板は、ずいぶん前に一度、書き込みさせてもらったことがありますが いつも、ROMのUO3です。ichinoseさんには別の場所で、いつもご指導いただいています。 みなさんのやりとり、興味深く、また楽しく拝見。 私が現役のプログラマーだった大昔、そのころは皆さんがホストマシーンとか汎用機と呼んでおられる 今なら博物館に鎮座しているようなシロモノで、しかも事情があってアセンブラーでした。 でも、そういう環境で、好き勝手なプログラミングになることを避けるために、ichinoseさんが おっしゃっている、Object指向や、コード記述方式の統一も含めた開発方法論といったものを 強く意識して仕事をしていました。（もちろん、Object指向などというシャレた名前はありませんでしたが）
ということで、ichinoseさんのご趣旨は極めてよく理解できます。 ただ、なんといいましょうか、個人差はあると思いますが、VBAの世界は、エクセルから入り いわゆる「マクロ」という「エクセル操作の補助」といったところに進み、それから、ベースがVBですから もう少し複雑なプログラミングに入っていく。もしかしたら「マクロ」段階で充分な人もおられるかも しれません。
あまり、こうだ、ああだという議論より、自分のレベルに合ったコードを書いていくうちに 困ったことがさまざまでてきて、あぁ、ichinoseさんがおっしゃっていたのは、こういうことだったんだと そう実感できるときに、それを理解しても遅くはないのかなとも思います。
UO3
この件に関しては、申し上げたいことは既に記述してしまったのですが、 「汎用機」なんて懐かしい記述があり、とするとUO3さんは、私と殆ど同世代（UO3さんがちょっと上かなあ）？ なんて思ったりしたものですから、再々で投稿します。 私がソフト会社に入社した年が1983年です。入社時に配属されたプロジェクトは、 凍結間近のシステムの保守管理でした（UO3さん同様アセンブラで書かれていました。 もっとも、私がここでアセンブラを記述したのは、100行あったかどうかでしたが）。 よって、誰も暇・・・、新人の私は、 構造化を新人教育として、先輩方が入れ替わり立ち代りで 指導してくれました。 忙しいプロジェクトに配属された同期に比べると基礎をみっちり教育されたという 思いがあります。
この経験から、私は、この手のことは、後でなく、プログラミングのやり始めがよい という判断をしています。
>マクロ」段階で充分な人 やはり、分岐点はここでしょうか？ これは、わかります。が、一々VBAに対する価値観を確認してから、というのもなんですからねえ。 こういう方には、私の記述は流していただければよいと思っています。 今回の投稿で掲示板に記述するって、何年もやってきていますが、 改めて色んな配慮をしなければ、良いスレッドにならないなあ と痛感しています。
私は、今後も構造化プログラミングについては、必要に応じて記述していくつもりでいます。 が、その投稿の仕方というか記述については、十分な配慮が必要 と反省しました。 日頃からわかっているつもりでいましたが、慣れだったのでしょうかねえ、いかんなあ
ｍｏｍｏさんとUO3さんのご意見には、感謝いたします。ご意見のおかげで 自分の投稿を再々で読み返し、私なりに問題点を見出すことが出来ました。
ichinose
おはようございます。
>書物を読まずとも、 >構造化プログラミングの概念がが自然に身に付いているのかも知れませんねえ。
お褒めのお言葉と受け止めます。感謝します。 私はプログラマでもなんでもない、ただのエクセル好きなので皆様には到底及ばないです。
実は今の私があるのはichinoseさんのおかげといっても過言ではありません。 以前、他の板（緑色の）で違うHNでしたがインスタンスなどの基本を しっかり優しく教えて頂きました。 いつか回答者になって恩返しをしようという思いでここまで来れました。
>>全員が同じコードの書き方しかできない言語なんてつまらないですし。 >ただ、プログラミング技法ってのは↑この考え方と逆の観点から生まれてきたのでは？
これに関しては私の発言場所が不適切というか・・・ たとえば最終行を得るのに私はFindメソッドを使いますが、多くの方はEndプロパティを使う。 Endでも出来るけどFindでも出来る、双方にメリットがあってどっちを使う？ というような場面での話でした。（Findのメリットは引数のxlValuesだと私は実感）
たびたび、質問者さん不在のままで申し訳ありませんが このようなスレッドは非常に身になります。ありがとうございます。 （ｍｏｍｏ）
[ 一覧(最新更新順) ]
YukiWiki 1.6.7 Copyright (C) 2000,2001 by Hiroshi Yuki.
Modified by kazu.