UserFormのTextBoxのプロパティの違い

質問

UserFormのTextBoxのプロパティのValueプロパティとTextプロパティはどちらも同じ値が表示されますが、この2つのプロパティは何が違うのでしょうか?
　もし同一のものならばどちらか一方のみがあれは済む話ではないでしょうか?

※ 別にどちらを使えば良いのか迷っている訳ではありませんので、「どちらでも良い」といった類の回答は御遠慮願います。

回答No.8

unokwave · ベストアンサー

>Cells(1, 2).Text = TextBox1.Text
>
>ではエラーとなってしまい、TextBoxのTextプロパティの値はセルのTextプロパティには転記出来ませんから、この2つのTextプロパティが同じ機能とは言えないのではないでしょうか。

基本的にVBの仕様としてはvalueが値の入出力、textは表示文字列の取得(出力)です。
プロパティの機能はクラスごとに上書きできますから、何らかの理由があって一方は書き込み禁止、一方は書き込み可能にしたのでしょう。
書き込み可否以外は他と変わりませんし。

一部の仕様が違う事は継承と何の関係もありません。
わかり難さを気にしなければ継承してもまったく異なる機能を持たせることも可能ですから。
これは設計者次第です。

>それは車輪の再発名と変わりのない無駄な事である様な気がします。

その点を理解するにはVBAではなくVB.NETでジェネリックについて経験を積んでください。
それとプログラミングに関する話題は開発者カテゴリーでおこなって下さい。

>兎に角、一般ユーザーが取り扱う上では、TextBoxのValueプロパティとTextプロパティは同じもので、差はないので、どちらを使うかは気にしなくても良いと考えておけば宜しいのでしょうか?

現時点でのExcelのUserFormのTextBoxについてはその通りでしょう。
Accessではformatプロパティがあって変更できる仕様になっていますが、Excelも同様の仕様に改められる可能性がありますので。

お礼

御回答頂き有難う御座います。

>その点を理解するにはVBAではなくVB.NETでジェネリックについて経験を積んでください。

　了解致しました。本件に関して素人にも解りやすい説明をする事は困難であり、疑問を解決するには疑問を持った側にもそれなりの知識が必要だという事なのですね。
　私にはそこまでの知識が御座いませんので、これ以上、深く答えを追及する事は諦める事に致します。

>それとプログラミングに関する話題は開発者カテゴリーでおこなって下さい。

　申し訳御座いませんが、私が利用しているサイトであるOKWaveには開発者カテゴリーは存在していないようです。
　それに、今回は別に新たなプログラムを開発するという話ではなく、単に「同一のデータしか扱う事のないプロパティが2つもあるのは、何か違いが設けられていて、取り扱う上で何か注意しなければならない事があるかも知れない」と考えて、実用上は問題なくとももしも注意する点があるのであれば念のためにそれを知っておきたいと思っただけの事なのです。
　そこで、このサイトにはVBAに関する質問もExcelカテゴリーに投稿されて来る事が珍しくなかったため、開発者カテゴリーやそれに相当する様な仰々しいカテゴリーは避けて、Excelカテゴリーに投稿した次第です。

　素人の細やかな疑問にここまでお付き合いして下さり感謝致します。

回答No.7

unokwave

ですから
>ExcelのUserFormのTextBoxにはformatプロパティが存在しませんが、セルには存在します。
これらは機能と名称からして同じ継承系譜にあります。

です。
formatプロパティを持つセルのTextBoxはvalueとtextで異なる結果を得る仕様があるので基底クラスにtextを用意していて、それを継承しているUserFormのTextBoxにもtextが引き継がれているのだろうと推測していて、UserFormのTextBoxにはformatがないのでvalueとtextで得られる値に差がないと言うわけです。
以前にも書いたように、このあたりは設計する人の意図次第ですから、設計者ではない私に「何故でしょうか」と訊かれても推測以上はできません。

お礼

御回答頂き有難う御座います。

>ですから
>>ExcelのUserFormのTextBoxにはformatプロパティが存在しませんが、セルには存在します。
>これらは機能と名称からして同じ継承系譜にあります。

との事ですが、実際、

Cells(1, 2).Text = TextBox1.Text

ではエラーとなってしまい、TextBoxのTextプロパティの値はセルのTextプロパティには転記出来ませんから、この2つのTextプロパティが同じ機能とは言えないのではないでしょうか。
　むしろ、TextBoxのValueプロパティとTextプロパティの方が、セルのValueプロパティやTextプロパティに反映させようとした場合の結果が同じなのですから、TextBoxのValueプロパティとTextプロパティの方が同じ機能・系譜であるかの様にさえ思えます。

>formatプロパティを持つセルのTextBoxはvalueとtextで異なる結果を得る仕様があるので基底クラスにtextを用意していて、それを継承しているUserFormのTextBoxにもtextが引き継がれているのだろうと推測していて

　ですから、TextBoxのTextプロパティの値はセルのTextプロパティには転記出来ませんから、TextBoxのTextプロパティはセルのTextプロパティとは仕様が異なっているという事になりますので、継承しているとは言えないのではないでしょうか?

>UserFormのTextBoxにはformatがないのでvalueとtextで得られる値に差がないと言うわけです。

　同一のデータを出力するために、態々異なる2つの方法を使っているという事なのでしょうか?
　それは車輪の再発名と変わりのない無駄な事である様な気がします。

　兎に角、一般ユーザーが取り扱う上では、TextBoxのValueプロパティとTextプロパティは同じもので、差はないので、どちらを使うかは気にしなくても良いと考えておけば宜しいのでしょうか?

回答No.6

unokwave

>「データというものは送られた先で基底クラスごとに異なる動作をするものであり、データの受け手側(データを送られた側)は基底クラスの異なるデータを受け取った場合、データの動きを無効にし、その代わりに基底クラスが同じデータを受け取った場合と同じ動作を、そのデータにさせる事が出来る」
という様な事なのでしょうか?

概ね合っていますが、誤解のないように訂正します。
「データ処理はクラスごとに異なる処理をさせる事が可能で、プロパティを上書きしなければ継承元クラスのプロパティを呼び出す」

>どちらか一方のプロパティのデータさえ用意しておけば、例えデータの送り先が基底クラスの異なる方式でデータを取り扱っていたとしても、データを問題なくやり取りする事が出来るという事ではないのでしょうか?

概ね合っていると解釈できますが、誤解のないように訂正します。
「どちらか一方のプロパティのデータさえ用意しておけば、例えデータの送り先クラスが異なる方式でデータを取り扱っていたとしても、データを問題なくやり取りする事が出来るようにTextBoxは作られている」

>TextBoxにはformatプロパティが用意されていないのですから、

ExcelのUserFormのTextBoxにはformatプロパティが存在しませんが、セルには存在します。
これらは機能と名称からして同じ継承系譜にあります。

>データの送り先で勝手に異なる結果に変更されたのでは不味いと思います。

変換されるかは呼び出すプロパティがどのクラスの物なのかによって左右されます。
どのクラスを利用するかはプログラミングの際に指定しますから何の問題もありません。

お礼

御回答頂き有難う御座います。

>「どちらか一方のプロパティのデータさえ用意しておけば、例えデータの送り先クラスが異なる方式でデータを取り扱っていたとしても、データを問題なくやり取りする事が出来るようにTextBoxは作られている」

という事に関して確認してみましたが、その様にはなっていない様です。
　ユーザーフォーム上に1個のTextboxと8個のCommandButtonを作成し、VBAにて以下の様なマクロを組んでみたのですが、

Sub CommandButton1_Click()

TextBox1.Value = Cells(1, 1).Value

End Sub

Private Sub CommandButton2_Click()

TextBox1.Value = Cells(1, 1).Text

End Sub

Private Sub CommandButton3_Click()

TextBox1.Text = Cells(1, 1).Value

End Sub

Private Sub CommandButton4_Click()

TextBox1.Text = Cells(1, 1).Text

End Sub

Private Sub CommandButton5_Click()

Cells(1, 2).Value = TextBox1.Value

End Sub

Private Sub CommandButton6_Click()

Cells(1, 2).Value = TextBox1.Text

End Sub

Private Sub CommandButton7_Click()

Cells(1, 2).Text = TextBox1.Value

End Sub

Private Sub CommandButton8_Click()

Cells(1, 2).Text = TextBox1.Text

End Sub

その結果は以下の様な事になりました。

CommandButton1を押した結果
　TextBox1=2001/03/14 , A1セルの表示=平成13年3月14日

CommandButton2を押した結果
　TextBox1=平成13年3月14日 , A1セルの表示=平成13年3月14日

CommandButton3を押した結果
　TextBox1=2001/03/14 , A1セルの表示=平成13年3月14日

CommandButton4を押した結果
　TextBox1=平成13年3月14日 , A1セルの表示=平成13年3月14日

CommandButton1 or 3を押した後、CommandButton5を押した結果
　TextBox1=2001/03/14
　B1セルの表示(表示形式:標準)=2001/03/14　(日付データ)

CommandButton1 or 3を押した後、CommandButton6を押した結果
　TextBox1=2001/03/14
　B1セルの表示(表示形式:標準)=2001/03/14　(日付データ)

CommandButton2 or 4を押した後、CommandButton5を押した結果
　TextBox1=平成13年3月14日
　B1セルの表示(表示形式:標準)=平成13年3月14日　(文字列データ)

CommandButton2 or 4を押した後、CommandButton6を押した結果
　TextBox1=平成13年3月14日
　B1セルの表示(表示形式:標準)=平成13年3月14日　(文字列データ)

CommandButton7を押した結果 : エラーのため実行不可

CommandButton8を押した結果 : エラーのため実行不可

　この様に、セルから転記する値がTextプロパティの値なのかValueプロパティの値なのかによってTextBoxに表示される文字列は(当然の事ながら)変わりましたし、セルのTextプロパティの値としてはTextBoxのValueプロパティの値もTextプロパティの値も使う事が出来ませんでした。
　そして、セルのValueプロパティの値としてはTextBoxのValueプロパティの値もTextプロパティの値も使う事が出来ましたし、その際変換されるか否かはセルへと転記するTextBoxのデータのプロパティがValueプロパティの値でもTextプロパティの値でも変わりがありませんでした。(どちらも同じ文字列データなのですから当たり前です)
　ですから、TextBoxのデータの場合、

>それにformatプロパティを用意してあるクラスではvalueとtextで異なる結果を得ることができるようになっているわけです。

とはなっていないという事になります。
　TextBoxに用意されているValueプロパティとTextプロパティのどちらを用いても結果は同じでなのですから、2つを用意する事に意味がある様には思えません。
　それにもかかわらず、何故同じ値しか示す事のないプロパティが2つも用意されているのでしょうか?

回答No.5

unokwave

>側で勝手にTextプロパティと基底クラスが同じデータに変換してくれる筈という事になるのですから、TextBoxにはTextプロパティは必要ないという事になるので
>どちらか一方のみがあれは済む話ではないでしょうか?

いいえ。
まず基底クラスが同じデータに変換しようと、継承クラス(サブクラス)はそのプロパティの動作を上書きして動作を変更できます。
それにformatプロパティを用意してあるクラスではvalueとtextで異なる結果を得ることができるようになっているわけです。

>態々プロパティの数を１つ余分に設けている理由が解りません。

変換して渡すという汎用的用途があるからでしょう。
このメリットを説明するのはかなり難しいのですが、掘り下げた内容を書いてみて要約が難しいので諦めます。
変換して渡す用途があちこちにあって、別途用意するメリットがあるとMicrosoftの担当開発者が経験上判断した、そう考えてもらうか、実際にソフトウェア開発で色々な用途向けのソフトウェアを幾つも作ってみると納得できるかも知れません。

ソフトウェア開発を経験すると、機能の分類や整理に迷うことになります。
それはデータを分類すると複数のカテゴリの属性を持つ物に出会い、分類に悩むのと似ています。

お礼

御解答頂き有難う御座います。

>まず基底クラスが同じデータに変換しようと、継承クラス(サブクラス)はそのプロパティの動作を上書きして動作を変更できます。

　仰る意味が良く理解出来なかったのですが、もしかしますと
「データというものは送られた先で基底クラスごとに異なる動作をするものであり、データの受け手側(データを送られた側)は基底クラスの異なるデータを受け取った場合、データの動きを無効にし、その代わりに基底クラスが同じデータを受け取った場合と同じ動作を、そのデータにさせる事が出来る」
という様な事なのでしょうか?
　この理解の仕方で合っているのかどうかは判りませんが、もし仮に合っているとした場合には、それは要するに

>>異なる結果が欲しい機能下
>の側で勝手にTextプロパティと基底クラスが同じデータに変換してくれる

のと同じ事であり、基底クラスの異なるデータを送ったとしても、データの受け手はそのデータを「基底クラスが同じデータ」と同様に正しいやり方(動作)で取り扱う事が出来るという事ですから、ValueにするかTextするかは兎も角、どちらか一方のプロパティのデータさえ用意しておけば、例えデータの送り先が基底クラスの異なる方式でデータを取り扱っていたとしても、データを問題なくやり取りする事が出来るという事ではないのでしょうか?

>それにformatプロパティを用意してあるクラスではvalueとtextで異なる結果を得ることができるようになっているわけです。

　何を仰りたいのかという事が良く解りません。
　TextBoxにはformatプロパティが用意されていないのですから、ValueプロパティのデータとTextプロパティのデータを区別する必要はないという事になりますので、尚の事、どちらか片方のプロパティさえあれば良いという事になる様に思えます。
　加えて、TextBoxのデータはValueプロパティのデータもTextプロパティのデータもどちらも同じ文字列データとなっているのですから、データの送り先で勝手に異なる結果に変更されたのでは不味いと思います。
　その様な恐れがあるのでしたら、勝手に異なる文字列に変換されてしまう恐れのあるValueプロパティは使わずに、Textプロパティのみを使う様にした方が良いという事になるのではないでしょうか?

回答No.4

unokwave

>基底クラスが異なると回答者様が仰っておられる「TextBoxのValueプロパティ」と「ConfirmButton等のValueプロパティ」が、同名であるのはおかしいという事になってしまいます。

車輪の再発明を避ける方法は幾つかありますが、一つはクラス(コントロール)を継承して再利用しやすくする設計と、ソースコードを流用して別の用途向けにも採用する方法とがあります。
メソッド(プロパティ)はクラスに対する入出力インターフェースでしかない事が多く、手続き上呼び出し名が必須で付いているのであって、中身は誰でもできる応答を僅かに記述しているだけという事が多く、再利用のための管理をするほうが手間が掛かる場合には個々に記述する事が理に適っているとして扱われます(再発明の揶揄対象にはならない)。

このあたりはソフトウェアの開発経験がないとわかりにくいかも知れません。
ソフトウェアを作るというのは文章書きのような作業で、機能に応じて書く文章が増えていきます。
その量は喩えるなら数万ページ数百万ページの文章といった甚大な量になる事もあります。
以前書いた文章と僅かでも齟齬があるとバグになり、全体を網羅してバランスを考慮する必要があり、動作環境のメモリといったリソースを考慮して動的にバランスをとる事も必要で、といった具合に複雑さは多岐にわたります。
なので動作確認を経たソースコードの確かさは重要で、少量の文章を書いただけでも俯瞰し直してみれば懸念点が見つかる事が珍しくない人間にとって、開発時間の短縮と全体ボリュームを安易に増やさず把握しやすくする書き方が重要になります。

そういった理由で車輪の再発明が馬鹿にされ、いたずらに手間を増やしてしまうような細部の再発明防止は無視されます。
コントロールは少なくとも管理するに相応しいだけのボリュームがある部品です。
プロパティが同名なのは統一性によって設計上や利用者が把握しやすくするためです。
なので同一名のプロパティは他コントロールと同一性を意味しません。

最初に
>コントロールは同名なら基底クラスが同じ
と書いているように車輪の再発明対象はコントロールであってプロパティではありません。
出だしから勘違いした私のように、そしてプロパティも車輪の再発明の対象と勘違いしてしまったあなたのように、人間の文章把握能力は不確かで遅く、高品質のソフトウェアを迅速に作る上で車輪の再発明防止が必須だけれど、過度にやり過ぎると却って邪魔になると言うわけです。

お礼

御解答頂き有難う御座います。

　却って解らなくなりました。

>メソッド(プロパティ)はクラスに対する入出力インターフェースでしかない事が多く、手続き上呼び出し名が必須で付いているのであって、中身は誰でもできる応答を僅かに記述しているだけという事が多く、

>プロパティが同名なのは統一性によって設計上や利用者が把握しやすくするためです。
>なので同一名のプロパティは他コントロールと同一性を意味しません。

という事であれば、ValueプロパティとTextプロパティは何が違うのでしょうか?

>中身は誰でもできる応答を僅かに記述しているだけという事が多く、

という事であれば、結局、

>>異なる結果が欲しい機能下

>にデータを渡す際には、TextBoxに関してはValueプロパティの値である"文字列"(Valueプロパティ用の基底クラスのデータではなく、「文字列」としてのデータ)を、Textプロパティの値としてそのまま渡せば、

>>異なる結果が欲しい機能下

>の側で勝手にTextプロパティと基底クラスが同じデータに変換してくれる筈という事になるのですから、TextBoxにはTextプロパティは必要ないという事になるので

>どちらか一方のみがあれは済む話ではないでしょうか?

　それとも、世の中にはプロパティが「Text」でなければデータを受けとろうとしない融通の利かないプログラムが存在していて、そういったプログラムのためだけに態々プロパティの数を１つ余分に設けているだけだと考えれば宜しいのでしょうか?
　しかしそれならば、その様なプログラムにデータを渡す際にプロパティの名称のみを「Value」から「Text」に付け替えて渡せば良いのですから、態々プロパティの数を１つ余分に設けている理由が解りません。

回答No.3

unokwave

>ConfirmButtonやOptionButton、Label、CheckBox等々もValueプロパティがあるのですから、Textプロパティも必要という事になる筈ですが、それらに関しては実際にはTextプロパティがありません。

ConfirmButton等の基底クラスはTextBoxとは異なります。
TextBoxのサブクラスには書式指定を伴う汎用的用途が意図されているため、値そのままのvalueと書式指定による表示用のtextがそれぞれ用意されているのだろうと言えます。

>TextBoxの場合も入れる事が出来るのは文字列データのみで数値データを入れる事が出来ないのですから

valueは数値を意味しているわけではありません。
例えば日付のYYYY/MM/DD形式の文字列を入れたとして、米国のロケールで書式指定にはロング形式の指定をした場合、Week-name, DD Month-name YYYYという形式でtextから取り出せることになります。

お礼

御解答頂き有難う御座います。

　只、折角御解答頂いたところ申し訳御座いませんが、仰る事が良く解りませんでした。

>ConfirmButton等の基底クラスはTextBoxとは異なります。
>TextBoxのサブクラスには書式指定を伴う汎用的用途が意図されているため、値そのままのvalueと書式指定による表示用のtextがそれぞれ用意されているのだろうと言えます。

との事ですが、基底クラスが異なるという事でしたら、

>Microsoftのコントロールは同名なら基底クラスが同じ(ソフトウェア業界では同じような機能を別途作る行為を「車輪の再発明」と呼び馬鹿にします)です。

なのですから、基底クラスが異なると回答者様が仰っておられる「TextBoxのValueプロパティ」と「ConfirmButton等のValueプロパティ」が、同名であるのはおかしいという事になってしまいます。

>valueは数値を意味しているわけではありません。

　はい、

>TextBoxの場合も入れる事が出来るのは文字列データのみ

と書いております様に、私もTextBoxのValueプロパティは数値ではないと申しております。

>例えば日付のYYYY/MM/DD形式の文字列を入れたとして、米国のロケールで書式指定にはロング形式の指定をした場合、Week-name, DD Month-name YYYYという形式でtextから取り出せることになります。

という事であれば、

>異なる結果が欲しい機能下

にデータを渡す際には、TextBoxに関してはValueプロパティの値である"文字列"(Valueプロパティ用の基底クラスのデータではなく、「文字列」としてのデータ)を、Textプロパティの値としてそのまま渡せば、

>異なる結果が欲しい機能下

の側で勝手にTextプロパティと基底クラスが同じデータに変換してくれる筈という事になるのですから、TextBoxにはTextプロパティは必要ないという事になるのではないでしょうか?

回答No.2

unokwave

>"セルの"プロパティに関して尋ねているものでは御座いません。

申し訳ありません、完全に読み違えていました。

但しMicrosoftのコントロールは同名なら基底クラスが同じ(ソフトウェア業界では同じような機能を別途作る行為を「車輪の再発明」と呼び馬鹿にします)です。
ある機能下のコントロールでは差異がなく、別の機能下のコントロールでは差があると言うことは、用途の異なる目的向けのメソッド(VBA用語ではプロパティ)を基底クラスに用意してあって、差をつける必要のない機能下では同じ結果が得られ、異なる結果が欲しい機能下でのみ異なる結果を返すように作っているのだと思います。

それを裏付けるオフィシャル情報は(Excelについては見つからずAccess用解説ですが)
https://msdn.microsoft.com/en-us/library/office/ff193552.aspx

あなたの質問と同じ要素を含む別の質問に対するMVP資格所有者の回答からもそれを掴めます。
https://social.msdn.microsoft.com/Forums/en-US/0c05c05b-12c7-4d41-81bd-39a859d1b026/formatting-display-of-excel-userform-text-boxes?forum=isvvba

お礼

御解答頂き有難う御座います。

>差をつける必要のない機能下では同じ結果が得られ、異なる結果が欲しい機能下でのみ異なる結果を返すように作っているのだと思います。

　それは、計算のために数値データを扱い、表示形式で見かけを変える必要のあるセルの場合はTextプロパティとValueプロパティの違いが生じて、計算を行う必要がないTextBoxの場合はTextプロパティとValueプロパティの値に違いを設ける必要がないというような事なのでしょうか?
　しかしながら、

>差をつける必要のない機能下

であってもValueプロパティとは別にTextプロパティも必要だという事であれば、ConfirmButtonやOptionButton、Label、CheckBox等々もValueプロパティがあるのですから、Textプロパティも必要という事になる筈ですが、それらに関しては実際にはTextプロパティがありません。
　もしも、TrueとFalseの論理データしか入らないのでTextプロパティが不要だという事でしたら、TextBoxの場合も入れる事が出来るのは文字列データのみで数値データを入れる事が出来ないのですから、TextBoxにもTextプロパティは不要という事になるのではないでしょうか?

回答No.1

unokwave

セルのフォーマット書式によっては異なる結果が得られるのだそうです。
詳しくは
https://fastexcel.wordpress.com/2011/11/30/text-vs-value-vs-value2-slow-text-and-how-to-avoid-it/

お礼

御回答頂いた事には感謝致します。

　しかしながら、本質問は

>UserFormのTextBoxのプロパティ

に関して尋ねているものでして、"セルの"プロパティに関して尋ねているものでは御座いません。
　添付頂いたURLのページも拝見させて頂きましたが、「"Rangeオブジェクトの"TextプロパティとValueプロパティ」に関する話ばかりで、「UserFormのTextBoxのValueプロパティやTextプロパティ」に関する情報を見つける事は出来ませんでした。
　私も詳しくは御座いませんが、UserFormのTextBoxにはフォーマット書式を設定するためのプロパティは見当たりませんでしたので、

TextBox1.Value　で取得出来る値

と

TextBox1.Text　で取得出来る値

に違いが出るとは思えませんし、取得した値が同じであれば、その値をセルに転記した際に

>セルのフォーマット書式によっては異なる結果が得られる

とは思えないのですが、具体的にはどの様に異なる結果が得られる場合があるのでしょうか?