none
VB6.Format関数は、なぜ廃止された? RRS feed

  • 質問

  • VisualStdio2003で制作したソフトを、VisualStdio2015へ移行する作業をしています。
    VB6.Format関数を大量に使っているのですが、これらは廃止されたらしくワーニングエラーが出てしまい、代替案を模索中なのですが、和暦表示で困っています。

    VB6.Formatでは、「g」と「e」の組み合わせで「平成28年」「平28年」「H28年」など多様な出力ができ便利だったのですが、
    調べたところ、VB6.Formatを使わずにそれをやるには、かなり面倒くさいことをしないとならないそうで…。
    VB6.Formatのように、「簡単に」和暦出力ができるようではなさそうですね。

    これは私の考えですが、「廃止するからには、それにとって代わる代替案を提供すべきで、そしてその代替案は利便性を損なうものであってはならない。でないと代替案の意味がない」と考えています。
    にもかかわらず廃止されたのはなぜなのか?その理由を知りたいです。
    それか、もし私の考えが間違っているのなら、ご指摘ください。
    • 種類を変更済み 星 睦美 2016年10月4日 4:35 ディスカッション
    • 種類を変更済み 星 睦美 2016年10月4日 4:50 適切と判断して元に戻します。
    2016年10月3日 4:53

回答

  • > これらは廃止されたらしくワーニングエラーが出てしまい、

    ObsoleteAttribute 付きなので 警告BC40000 が通知されますが、廃止ではなく非推奨なだけで、一応使う事はできます。

    ただし VB2015 の場合は、以下のようにして警告を抑制できます。
    下記は、Format 関数の警告を抑制するためのラッパーメソッドです。

    Module Module1
    
    #Disable Warning BC40000, BC40008
        Public Function Format(Expression As Object, Optional Style As String = "", Optional DayOfWeek As FirstDayOfWeek = FirstDayOfWeek.Sunday, Optional WeekOfYear As FirstWeekOfYear = FirstWeekOfYear.Jan1) As String
            Return Global.Microsoft.VisualBasic.Compatibility.VB6.Support.Format(Expression, Style, DayOfWeek, WeekOfYear)
        End Function
    #Enable Warning BC40000, BC40008
    
    End Module


    上記を用意しておけば、警告なしで『 MsgBox(Format(Now, "yyyy(ge)/M/d")) 』を利用できます。

    ただしこの策が使えるのは、VB2015 以降のみです。
    VB2013 以下では #Disable Warning ディレクティブがサポートされていないため使えません。

    仮に 2013 以下で Obsolete のコンパイル時警告を抑制する必要がある場合は、リフレクションを用いて回避するという策があります。


    > 調べたところ、VB6.Formatを使わずにそれをやるには、

    VB5 までのバージョンは、多言語対応のために、各国語版のランタイムを用意する必要があり、また、OS 設定に依存する部分も多かったという問題がありました(日本は比較的恵まれていましたが)。多言語対応の流れの中で、StrConv などは、VB6 で第三引数(LocaleID)が追加されるなどの対応がなされたものの、Format に関しては手付かずでした。
    それが .NET では、System.Globalization 名前空間を用いる事で、その制限をかなり撤廃することができるようになっているわけで、その点は進化していると感じます。とはいえ今回の件も含め、個人的にはまだ十分では無いと感じていますけれども(ja-JP の "t" 書式とか何とかならないのか…)

    とはいえ、Format 関数を使い続けたいか、と問われると否定派です。使いやすいかどうかでも重要ですが、多少使いにくくても、まずは要件を満たせるかどうかの方が自分にとっては重要なので。だからどうするべきだ、という案があるわけでは無いのですけれども。


    > かなり面倒くさいことをしないとならないそうで…。

    楽になったところもあれば、面倒になったところもあるのは確かですね。特に .NET 1.0 Beta 2 当時(2001年後半)は、情報も少なくて大変でした。

    ただこの手の話は、定期的に繰り返される話題であるように思います。.NET 化の前、たとえば VB4 の 32bit 化の際にも互換性を問題視する声は挙がっていましたし、さらに遡れば、なんで VB は MML(Music Markup Language) をサポートしなかったんだ、なんていう意見もあったわけで。まぁ、MML については、限定的とはいえ奇跡の復活を遂げましたが。(Microsoft.SmallBasic.Library.Sound.PlayMusic メソッド)


    > VB6.Formatのように、「簡単に」和暦出力ができるようではなさそうですね。

    いずれにせよ、現時点で取りうる選択肢としては、
     (1) ObsoleteAttribute に目をつぶって互換メソッドを使い続ける
     (2) .NET 標準の書き方に順次置き換えていく
     (3) それが和暦だけの問題なら、独自に変換関数を自作する
     (4) 他のライブラリ――たとえば Oracle の和暦変換機能など――を流用する
    ぐらいだと思います。自分は(2)が多いです。

    どれが良いのかはケースバイケースなので、それぞれのメリットとデメリットを理解した上で判断してみてください。

    ただ (1) に関しては、将来的に廃止されるでしょうし、個人的にはお奨めしていません。今後、新機能が追加されることも絶望的ですしね。

    具体例を挙げれば、たとえば String.Format なら、新設されたタイムゾーン書式をサポートしますが、Format 関数では非対応といった点などです。VB6 時代に無かった書式を、互換メソッドに追加するわけにもいかないので仕方ないですけれどね…。


    それとは別に、そもそも和暦変換を OS 依存にしておくことを不安視する声もあり、自分の周りでは (3)が採用されるケースをしばしば目にします。Windows 7 以降では和暦を自作できるようになったものの、この機能をサポートしているのは .NET Framework 4 以降の JapaneseCalender クラスを使った場合であり、Format 関数は VBA も含めて非対応であるという事情も自作する理由の一つのようです。


    > それにとって代わる代替案を提供すべきで、

    代替案というなら、その一つが、Microsoft.VisualBasic.Compatibility.VB6.Support モジュールだと思いますよ。
    あくまでも一時凌ぎのものなので、置き換えが推奨されてはいるというだけで。

    その一方で、利用者側で代替策を講じることが困難な機能、たとえば StrConv などについては、互換機能であっても ObsoleteAttribute が付与されていませんね。

    Format にしても StrConv にしても、OS 依存な所が強く、VB5 当時でさえ、Win9x と NT 系とで動作が違うなどの問題は未だに抱えていますし、どこまでを下位互換としてサポートを続けるかの線引きがあったのだと思いますが、利用者側としてみれば、それが Format の「和暦」だけの問題であるのなら、それを解決するための支援メソッドを開発者自身が自作した方が手っ取り早いですし、それを実装するのはそう難しくないと思います。


    > そしてその代替案は利便性を損なうものであってはならない。

    私自身は、必ずしもそうは思わないという立ち位置ですが、それが理想論だったとしても、現実は非情です。マイクロソフトによる仕様の取捨選択の判断が適切であったのかどうかは人によって見解が分かれるところでしょうけれども、利用者の誰もが満足するような代替案をすべてに対して提供する事は、現実問題として不可能ですから、どうしても限定的なサポートになってしまう部分は出てくるはずです。

    今回の Format だけに限ればそれぐらい対応してよ、という声も個人的には分からなくないのですが、あちらを立てればこちらが立たず、というケースは常に生じます。その結果として、「私にとっては意味の無い事」のなすり付け合いになってしまい、不公平さや、あるいは予期していなかった事態を引き起こすといったことはあるわけで(.NET に限らず、Office VBA 界隈でもそういう事態を何度か経験しています…)、その時々で回避策を講じていくのが現実的かと。

    とはいえ、使いにくい物は使いにくいと言った方が良いでしょう。今回の件に限らず、具体的な良案あるいは問題点がある場合、それを Visual Studio の「フィードバックの送信」機能で提案あるいは報告することをお奨めします。その意見に同調するユーザーがとても多くなれば、もしかしたらたとえば日本やアジア圏向けの追加ライブラリが別形態(たとえば nuget)にて公開されるようなことも、運が良ければ起こるかもしれません。

    なお、MSDN フォーラムは Microsoft に愚痴を語る場では無いので、ここで語るだけでは現場の声は伝わりません。ここでのやり取りは、基本的にはユーザー同士の意見交換の場であり、公式なサポートを期待する場所ではありませんから、将来バージョンへのフィードバックを期待するのであれば、本来のルートで声を届けるべきかと思います。


    そういえば、KB418691 で知られる 旧 VB の Format 関数の動作仕様などは、日本の大手メーカー群からの声によって、仕様から不具合へと変更されて修正されたものだと聞いたことがあります。あくまでも噂程度ですし、もちろん国外からの声もあったのでしょうが、いずれにせよ、フィードバックは大事だと思いますよ。VB2005 で追加された My なども現場の声から生まれた物らしいです(結果としては賛否両論だったわけですが)。

    2016年10月3日 12:04

すべての返信

  • これは私の考えですが、「廃止するからには、それにとって代わる代替案を提供すべきで、そしてその代替案は利便性を損なうものであってはならない。でないと代替案の意味がない」と考えています。
    にもかかわらず廃止されたのはなぜなのか?その理由を知りたいです。
    それか、もし私の考えが間違っているのなら、ご指摘ください。

    VB6.Format自体がVB6からVB.NETへの移行のための互換機能であり、VB.NET本来の機能ではありません。VB.NETが公開されてから既に14年も経過しているわけで、いつまでも互換機能に頼っている方が間違っています。それどころか互換機能に対して代替案を求めるなど筋違いかと。

    なお、和暦については全く別の問題があります。仕様として明文化されていませんが、VB6当時のことですから明治・大正・昭和・平成にしか対応できていません。今後、新たな元号に改元された際にどうするかが定まっていないわけです。その状態で、VB6.Formatが明治M・大正T・昭和S・平成H以外の文字を返した場合にプログラム側が意図しない動作をするかもしれません。そうなると改元されてもVB6.Formatは平成Hを返さざるを得ないでしょう。

    個人的な想像ではありますがこういった事情もあり、VB6.Formatは廃止にせざるを得なかったのかもしれません。

    ところで、件のVB6.Formatとは具体的にはどのようなものでしょうか? ドキュメントを見ましても廃止とは書かれていないのですが…? 私がVBに不慣れなだけで、何か別のものなのかな…。

    • 回答の候補に設定 星 睦美 2016年10月4日 4:51
    2016年10月3日 5:47
  • >件のVB6.Formatとは具体的にはどのようなものでしょうか?
    指定した書式に変換してくれるものです。たとえば「ggee年mm月」と書式指定すれば、「平成28年10月」と文字変換してくれます。
    「32ビットプロセスでしかサポートされない時代遅れの関数だ」という旨のワーニングエラーが出ます。
    かといってToStringとかだと、和暦に対応してません。

    >互換機能に対して代替案を求めるなど筋違いかと。
    そうは思いません。
    たとえ互換機能だろうと。たとえ14年前の代物だろうと。たとえ改元後はサポートされないとしても。便利なものは、便利なのです。
    便利なものが使えなくなり、代替案も提供されない。これは「退化」であり、退化を憂う声が筋違いとは思いません。

    思うに、VB6とVB.NETでは、そもそもの作り・考え方が違うのでしょうね。
    今までVB6.Formatがサポートされたこと自体が、むしろ例外的なことなのかもしれません。
    「じゃぁVB.NETの作り・考え方で、同じものを提供してるの?」と問うと、それがないんですよ。そこを、問題視してるわけです。

    いや。あるにはあるけど、不十分で使いづらいんです。
    「平成」と書式変換する方法はあるにはあるけど、手間がかかる。
    「平」とだけ書式変換しようと思ったら、さらに手間がかかる。
    「H」となれば、なおさら手間がかかる。
    これが、現状なんですよ!
    VB6.Formatのように、直感的でスマートではない。
    要望が多そうな機能なのに、なぜ???というのが疑問です。
    2016年10月3日 6:48
  • 「要望が多そう」とイメージだけで語られても困りますので、他のスレッドでもありましたけど、本当に必要であれば、適切なサイトで要望を出して、賛同者を募り、開発チームを説得してください。

    // 私個人としてはどうでもいい機能なので、開発チームの労力は他の機能の実装に割いて欲しいところです。
    2016年10月3日 6:59
  • 「それをすべきかどうか?」は、要望の多寡だけで決めていいものとは思いませんけどね。
    2016年10月3日 7:37
  • 「それをすべきかどうか?」は、要望の多寡だけで決めていいものではありませんが、
    少なくとも質問者様が便利か否かで決めるものではありません。

    質問者様の他のスレッドも見させていただきましたが、すべて自分にとって使い難いから嫌だと
    仰られているように思えます。

    私としては、Hongliang様と同じく、どうでもいい機能なので、なくてもまったく困りません。
    和暦変換自体は.NETでも可能ですので、使いやすいようにラッパーメソッドを用意するだけの話です。


    • 編集済み uemu 2016年10月3日 8:39
    2016年10月3日 8:36
  • 個人的には他の方と同意見ですが、一応試してみました。開発環境は Visual Studio 2015、.NET Framework のバージョンは 4.6.1です。
    「廃止されています」と警告メッセージが出ますが、実際まだ使えるようです。(当然、非保障ですが・・・)
    警告がうざければ、#Disable Warning で警告を抑止することができます。

    ’ 参照に Microsoft.VisualBasic.Compatibility を追加
    Imports Microsoft.VisualBasic.Compatibility
    
    Module Module1
    
    #Disable Warning
        Sub Main()
            Console.WriteLine(VB6.Format(Now, "gggee年mm月dd日"))
            Console.WriteLine(VB6.Format(Now, "yyyy年mm月dd日"))
        End Sub
    End Module



    本フォーラムは、ユーザー(開発者)同士で情報交換を行うためのコミュニティです。初めて利用される方は、以下のアナウンスをご覧ください。 https://social.msdn.microsoft.com/Forums/ja-JP/ca9ecfb7-4407-4fcb-b8bd-207d68257e68?


    2016年10月3日 9:11
    モデレータ
  • > これらは廃止されたらしくワーニングエラーが出てしまい、

    ObsoleteAttribute 付きなので 警告BC40000 が通知されますが、廃止ではなく非推奨なだけで、一応使う事はできます。

    ただし VB2015 の場合は、以下のようにして警告を抑制できます。
    下記は、Format 関数の警告を抑制するためのラッパーメソッドです。

    Module Module1
    
    #Disable Warning BC40000, BC40008
        Public Function Format(Expression As Object, Optional Style As String = "", Optional DayOfWeek As FirstDayOfWeek = FirstDayOfWeek.Sunday, Optional WeekOfYear As FirstWeekOfYear = FirstWeekOfYear.Jan1) As String
            Return Global.Microsoft.VisualBasic.Compatibility.VB6.Support.Format(Expression, Style, DayOfWeek, WeekOfYear)
        End Function
    #Enable Warning BC40000, BC40008
    
    End Module


    上記を用意しておけば、警告なしで『 MsgBox(Format(Now, "yyyy(ge)/M/d")) 』を利用できます。

    ただしこの策が使えるのは、VB2015 以降のみです。
    VB2013 以下では #Disable Warning ディレクティブがサポートされていないため使えません。

    仮に 2013 以下で Obsolete のコンパイル時警告を抑制する必要がある場合は、リフレクションを用いて回避するという策があります。


    > 調べたところ、VB6.Formatを使わずにそれをやるには、

    VB5 までのバージョンは、多言語対応のために、各国語版のランタイムを用意する必要があり、また、OS 設定に依存する部分も多かったという問題がありました(日本は比較的恵まれていましたが)。多言語対応の流れの中で、StrConv などは、VB6 で第三引数(LocaleID)が追加されるなどの対応がなされたものの、Format に関しては手付かずでした。
    それが .NET では、System.Globalization 名前空間を用いる事で、その制限をかなり撤廃することができるようになっているわけで、その点は進化していると感じます。とはいえ今回の件も含め、個人的にはまだ十分では無いと感じていますけれども(ja-JP の "t" 書式とか何とかならないのか…)

    とはいえ、Format 関数を使い続けたいか、と問われると否定派です。使いやすいかどうかでも重要ですが、多少使いにくくても、まずは要件を満たせるかどうかの方が自分にとっては重要なので。だからどうするべきだ、という案があるわけでは無いのですけれども。


    > かなり面倒くさいことをしないとならないそうで…。

    楽になったところもあれば、面倒になったところもあるのは確かですね。特に .NET 1.0 Beta 2 当時(2001年後半)は、情報も少なくて大変でした。

    ただこの手の話は、定期的に繰り返される話題であるように思います。.NET 化の前、たとえば VB4 の 32bit 化の際にも互換性を問題視する声は挙がっていましたし、さらに遡れば、なんで VB は MML(Music Markup Language) をサポートしなかったんだ、なんていう意見もあったわけで。まぁ、MML については、限定的とはいえ奇跡の復活を遂げましたが。(Microsoft.SmallBasic.Library.Sound.PlayMusic メソッド)


    > VB6.Formatのように、「簡単に」和暦出力ができるようではなさそうですね。

    いずれにせよ、現時点で取りうる選択肢としては、
     (1) ObsoleteAttribute に目をつぶって互換メソッドを使い続ける
     (2) .NET 標準の書き方に順次置き換えていく
     (3) それが和暦だけの問題なら、独自に変換関数を自作する
     (4) 他のライブラリ――たとえば Oracle の和暦変換機能など――を流用する
    ぐらいだと思います。自分は(2)が多いです。

    どれが良いのかはケースバイケースなので、それぞれのメリットとデメリットを理解した上で判断してみてください。

    ただ (1) に関しては、将来的に廃止されるでしょうし、個人的にはお奨めしていません。今後、新機能が追加されることも絶望的ですしね。

    具体例を挙げれば、たとえば String.Format なら、新設されたタイムゾーン書式をサポートしますが、Format 関数では非対応といった点などです。VB6 時代に無かった書式を、互換メソッドに追加するわけにもいかないので仕方ないですけれどね…。


    それとは別に、そもそも和暦変換を OS 依存にしておくことを不安視する声もあり、自分の周りでは (3)が採用されるケースをしばしば目にします。Windows 7 以降では和暦を自作できるようになったものの、この機能をサポートしているのは .NET Framework 4 以降の JapaneseCalender クラスを使った場合であり、Format 関数は VBA も含めて非対応であるという事情も自作する理由の一つのようです。


    > それにとって代わる代替案を提供すべきで、

    代替案というなら、その一つが、Microsoft.VisualBasic.Compatibility.VB6.Support モジュールだと思いますよ。
    あくまでも一時凌ぎのものなので、置き換えが推奨されてはいるというだけで。

    その一方で、利用者側で代替策を講じることが困難な機能、たとえば StrConv などについては、互換機能であっても ObsoleteAttribute が付与されていませんね。

    Format にしても StrConv にしても、OS 依存な所が強く、VB5 当時でさえ、Win9x と NT 系とで動作が違うなどの問題は未だに抱えていますし、どこまでを下位互換としてサポートを続けるかの線引きがあったのだと思いますが、利用者側としてみれば、それが Format の「和暦」だけの問題であるのなら、それを解決するための支援メソッドを開発者自身が自作した方が手っ取り早いですし、それを実装するのはそう難しくないと思います。


    > そしてその代替案は利便性を損なうものであってはならない。

    私自身は、必ずしもそうは思わないという立ち位置ですが、それが理想論だったとしても、現実は非情です。マイクロソフトによる仕様の取捨選択の判断が適切であったのかどうかは人によって見解が分かれるところでしょうけれども、利用者の誰もが満足するような代替案をすべてに対して提供する事は、現実問題として不可能ですから、どうしても限定的なサポートになってしまう部分は出てくるはずです。

    今回の Format だけに限ればそれぐらい対応してよ、という声も個人的には分からなくないのですが、あちらを立てればこちらが立たず、というケースは常に生じます。その結果として、「私にとっては意味の無い事」のなすり付け合いになってしまい、不公平さや、あるいは予期していなかった事態を引き起こすといったことはあるわけで(.NET に限らず、Office VBA 界隈でもそういう事態を何度か経験しています…)、その時々で回避策を講じていくのが現実的かと。

    とはいえ、使いにくい物は使いにくいと言った方が良いでしょう。今回の件に限らず、具体的な良案あるいは問題点がある場合、それを Visual Studio の「フィードバックの送信」機能で提案あるいは報告することをお奨めします。その意見に同調するユーザーがとても多くなれば、もしかしたらたとえば日本やアジア圏向けの追加ライブラリが別形態(たとえば nuget)にて公開されるようなことも、運が良ければ起こるかもしれません。

    なお、MSDN フォーラムは Microsoft に愚痴を語る場では無いので、ここで語るだけでは現場の声は伝わりません。ここでのやり取りは、基本的にはユーザー同士の意見交換の場であり、公式なサポートを期待する場所ではありませんから、将来バージョンへのフィードバックを期待するのであれば、本来のルートで声を届けるべきかと思います。


    そういえば、KB418691 で知られる 旧 VB の Format 関数の動作仕様などは、日本の大手メーカー群からの声によって、仕様から不具合へと変更されて修正されたものだと聞いたことがあります。あくまでも噂程度ですし、もちろん国外からの声もあったのでしょうが、いずれにせよ、フィードバックは大事だと思いますよ。VB2005 で追加された My なども現場の声から生まれた物らしいです(結果としては賛否両論だったわけですが)。

    2016年10月3日 12:04
  • >少なくとも質問者様が便利か否かで決めるものではありません。
    >すべて自分にとって使い難いから嫌だと仰られているように思えます。
    「自分にとって」という視点ではなく、「こういうことができてもよさそうなのになぜできないんだろう?」という視点で物を言ってます。
    自分の要望が万人に共通、なんて思ってませんが、このような要望が上がることは容易に想像つきそうなものですからね。
    実際、本件について調べていく中で、「和暦を含んだ文字列から日付型への変換はできるのに、その逆ができないのは片手落ちではないか」という記事を見かけました。その通りだと思います。
    ここは不満を言う場でないことは承知の上ですが、できてもよさそうなことができないから、不満に転じてしまうのです。

    まぁ、自分も全体的なことはわかりません。
    自分の要望を通すと他で不具合が出たり、自分には知りえない問題があったりするのかもしれません。
    だけど…。だけどですよ?今まで便利にできたことができなくなったって、やっぱりおかしいじゃないですか。
    PCの世界は日々進歩し、そのたびにいろんな問題が起こるものかもしれないけれど、今までの便利さを壊さないうえで進歩すべき。それが大前提なはずじゃないですか?
    便利さを壊すようであればそれは、進歩ではなく暴走と呼ぶべきではないでしょうか?

    とりあえず本件は、独自の変換関数の自作で対応します。やれやれ…てな感じですが。
    2016年10月4日 2:43
  • 「自分にとって」という視点ではなく、「こういうことができてもよさそうなのになぜできないんだろう?」という視点で物を言ってます。
    自分の要望が万人に共通、なんて思ってませんが、このような要望が上がることは容易に想像つきそうなものですからね。
    実際、本件について調べていく中で、「和暦を含んだ文字列から日付型への変換はできるのに、その逆ができないのは片手落ちではないか」という記事を見かけました。その通りだと思います。
    ここは不満を言う場でないことは承知の上ですが、できてもよさそうなことができないから、不満に転じてしまうのです。

    そこれこそが「自分にとって」の視点だと自覚すべきです。まず世界中に和暦しか存在しないかのような考えを改めるべきで、.NET Frameworkでは14種類ほどの暦に対応しています(VB6では多分グレゴリオ暦と和暦の2つかな?)。このような多数の暦に対応する都合上、各々の暦(今回であれば和暦、JapaneseCalendarクラス)の操作が煩雑になっているだけです。

    ちなみに各文字列を得る方法について.NET Frameworkのソースコードを追いかけてみましたが…

    • 「平成」を得るのはそこそこ簡単
    • 「平」を得るのは面倒
    • 「Heisei」はそもそも内部データとして保持していない
    • 「H」は内部データとして保持しているので無理やりであれば得られる

    という状況でした。

    蛇足ですが、日付の表示形式は利用者がコントロールパネルで選択する設計となっているため、ここで選択した暦であればデフォルトで表示されるため、特別な手順を必要としません。(つまり、本スレッドは利用者が和暦を使用しないと宣言している環境下で、利用者の意思に反して和暦を表示する手段についての議論との認識です。)

    2016年10月4日 3:09
  • >そこれこそが「自分にとって」の視点だと自覚すべきです。
    それは違いますね。なぜなら、筋道を通して物を言ってますから。

    >世界中に和暦しか存在しないかのような考えを改めるべき
    そんな考え、してませんが?

    >利用者が和暦を使用しないと宣言している環境下で、利用者の意思に反して和暦を表示する手段についての議論
    設定に依存することは、知ってました。
    しかしその設定に、必ずしも利用者の意図が反映されているとは限りません。
    PCに不慣れでデフォルトの設定のままの利用者も大勢います。
    そのような環境下でも、和暦表示させたい。それが、開発者としての意思です。

    2016年10月4日 4:20
  • > VB6では多分グレゴリオ暦と和暦の2つかな?

    ヒジュラ暦もサポートされていますね。
    日本国内だとまずお目にかからないですけれども。

    Option Explicit
    Private Sub Command1_Click()
        Dim s As String
        Dim oc As VbCalendar
        
        oc = Calendar
        
        Calendar = vbCalHijri
        s = "ヒジュラ暦" & vbCrLf & Format(Now, "yyyy ,d mmmm")
        CreateObject("WScript.Shell").Popup s, , App.Title, vbInformation Or vbMsgBoxRtlReading
        
        Calendar = vbCalGreg
        s = "西暦" & vbCrLf & Format(Now, "mmmm d, yyyy") & vbCrLf _
          & "和暦" & vbCrLf & Format(Now, "ggge年m月d日")
        CreateObject("WScript.Shell").Popup s, , App.Title, vbInformation
    
        Calendar = oc
    End Sub




    2016年10月4日 4:44
  • 筋道を通して物を言ってますから。

    筋道が通っていません。最初のコメントに戻りますが、VB6.Format自体がVB6からVB.NETへの移行のための互換機能であり、VB.NET本来の機能ではありません。VB.NETが公開されてから既に14年も経過しているわけで、いつまでも互換機能に頼っている方が間違っています。それどころか互換機能に対して代替案を求めるなど筋違いかと。

    もし質問者さんが求めるのであれば、VB6の開発継続でしょう。

    なお、Microsoft社としての案内を見つけました。Microsoft.VisualBasic.Compatibility.VB6.<member> は互換性のために残され、32 ビット プロセス内でのみサポートされる

    設定に依存することは、知ってました。
    しかしその設定に、必ずしも利用者の意図が反映されているとは限りません。
    PCに不慣れでデフォルトの設定のままの利用者も大勢います。
    そのような環境下でも、和暦表示させたい。それが、開発者としての意思です。

    やはり世界中に和暦しか存在しないかのような考えが根底にあるように見受けられます。(Windowsおよび.NET Frameworkの設計を見る限り)言語ごとに用意されている暦で十分であり、利用者が暦を切り替えたり、複数の暦を同時に扱うことはあまり求められていないです(と私は考えます)。

    デフォルト値が意にそぐわない利用者や、設定変更を行えない不慣れな利用者などが「大勢い」るなどというのは質問者さんの個人的な見解でしかないのでは?

    2016年10月4日 6:08
  • 佐祐理さんは「互換性だから」という前提での主張ですが、私はそこは重視してません。
    それに個人的見解かどうかも、ここで問うつもりはありません。
    これ以上は平行線なのでこの辺にしておきます。
    2016年10月4日 6:32
  • この辺にするつもりだったけど、一言だけ。

    今回のMicrosoftさんの見解をまとめると、こんな感じでしょうか。
    「はい、VB6.Formatはもう互換なので廃止しまーす。今までそれに頼ってた人は他のやり方をやってねー。
    え?不便?知らないよ、そんなこと。
    とにかく他の方法を提供してるんだから、こっちとしてはやることやってるんだ。
    不便だっていうんなら、フィードバックで意見言ってね。
    でもそれを検討するかどうかはぼくちんの気分次第だから、そこんとこよろしくねー。」
    佐祐理さんに言わせると、これは筋違いじゃないんですね。

    一方、私の見解をまとめるとこんな感じです。
    「え?VB6.Format、廃止なの?今まで便利に使ってたのに、しょうがないなぁ。
    じゃぁ別のやり方提供されてるの?どれどれ?何これ、すごく不便なんだけど。使えないじゃん。
    ちょっとちょっと、カンベンしてよ。これで別のやり方って言えるの?
    廃止するなら、せめてちゃんとしたやり方を提供してから廃止してよ。まったくもぅ~」
    佐祐理さんに言わせると、これは筋違いなんですね。

    2016年10月4日 8:41
  • フォーラム オペレーターの星 睦美です。プルコギ さん、こんにちは。

    質問に書かれている「VB6.Format が廃止された」に関しては、フォーラム ユーザーからの「警告が表示され非推奨ではあるけれども使用することはできる」という返信に私から[回答の候補に設定] させていただきました。製品のフィードバックに関しては魔界の仮面弁士 さんからの返信がとてもわかりやすく説明されていると思いました。

    今回のフォーラムの回答がプルコギ さんのお役にたちましたら幸いです。今後ともフォーラムをよろしくお願いいたします。


    フォーラム オペレーター 星 睦美 - MSDN Community Support

    2016年10月4日 9:44
  • 質問者さんは常に感覚で語られていますが、Microsoft社は一貫性のある判断のもと、決定しています。時系列で説明すると

    • 1998年 Visual Basic 6.0リリース
    • 2002年 Visual Studio .net(.NET Framework 1.0)リリース。VB6からの移行には制限があります。
    • 2003年 Visaul Studio .net 2003(.NET Framework 1.1)リリース。VB6からの移行支援としてMicrosoft.VisualBasic.Compatibility.dllを追加しました。
    • 2008年 Visual Basic 6.0延長サポート終了
    • 2010年 Visual Studio 2010(.NET Framework 4.0)リリース。サポート終了のためVB6からの移行は打ち切りました。Microsoft.VisualBasic.Compatibility.dllは廃止予定とします。

    となっています。質問者さんはMicrosoft.VisualBasic.Compatibility.dllのCompatibilityの語に込められた意味についてよく理解すべきです。

    また、.NET Frameworkに要望があるのであれば、VB6.Fromatに固執するのではなく、例えば

    • String.Format()メソッドの改善
    • Calendarクラスの扱いの改善

    など、.NET Frameworkに対しての要望を出せばいいと思います。

    # ただし、本スレッドでも何人かコメントされていますが特に必要としていないという声もありますし、(過去に同様の要望があったのかは知りませんが)現実問題として特に改良はされていません。

    2016年10月4日 9:45
  • > String.Format()メソッドの改善
    > Calendarクラスの扱いの改善

    改善提案を語るなら、個人的には、補間文字列(Interpolated Strings) にて、CultureInfo.OptionalCalendars を指定する機能が欲しいです。

    Excel のセル書式だと、LCID を指定した『[$-411]yyyy"年("ggge"年)"m"月"d"日["aaa"]"』 といった指定ができますよね。あんな感じで、 選択可能な暦を埋め込めむような仕様が設けられないかなー、と。

    現状は、西暦と元号を一つの書式の中にまとめられないので、面倒に感じている次第。

    まぁ、和暦と西暦で個別に変換してから繋げるとか、あるいは下記のように処理すれば回避できるので、現状の仕様で困るわけでも無いのですけれども。

    Dim jp As New CultureInfo("ja-jp", True)
    jp.DateTimeFormat.Calendar = New JapaneseCalendar()
    
    Dim dt As Date = #10/4/2016#
    
    '『2016(平成28)年10月4日[火]』
    Console.WriteLine(String.Format(jp, "{0}{1:(gggy)年%M月%d日[ddd]}", dt.Year, dt))
    
    '『2016(平成28)年10月4日[火]』
    Dim fmt1 As FormattableString = $"{dt.Year}{dt:(gggy)年%M月%d日[ddd]}"
    Console.WriteLine(fmt1.ToString(jp))
    
    '『2016(平成28)年10月4日[火]』
    Dim fmt2 As IFormattable = $"{dt.Year}{dt:(gggy)年%M月%d日[ddd]}"
    Console.WriteLine(fmt2.ToString(Nothing, jp))
    
    'これはNG
    '『2016(西暦16)年10月4日[火]』
    'Dim fmt3 As String = $"{dt.Year}{dt:(gggy)年%M月%d日[ddd]}".ToString(jp)
    'Console.WriteLine(fmt3)
    2016年10月4日 12:19
  • 少し話はそれますが、Visual Studio UserVoice のサイト見てると面白いですね。
    Visual Basic のカテゴリーを開くと、VB6をオープンソース化しようとか、新しい VB6 を開発すべきだとか、C# にならって B#(Basic#)と名前を変えるべきだとか、VB6 の次バージョン VB7 を作れ等、様々な提案がなされてますが、想像以上にVB6ユーザーが多いことには驚かされます。

    https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/category/30933-languages-visual-basic


    本フォーラムでは、私も含めプルコギさんの意見に賛同する人が殆どいないようですが、UserVoice では賛同される方が多いかもしれません。賛同者を1000人以上集められれば、Microsoft も考慮せざるを得なくなる可能性が高くなります。

    また UserVoice は Visual Studio の開発チームの人間(ただし米国スタッフ)も覗いているので、英語が出来ればより意見をダイレクトに伝えられると思います。

    Visual Studio のメニューから「ヘルプ」→「フィードバックの送信」→「提案の送信」をクリックすると、Visual Studio UserVoice のページに移動します。 「I suggest you ... 」 の下の TextBox に何か文字を入力すると、「Post a new idea...」 というボタンが表示されます。そこをクリックすると、タイトルと内容を入力できるようになります。提案は英語が多いですが、日本語の提案もかなりなされてますので、現状に不満あればこちらでダイレクトに意見を伝えた方がいいと思います。

    以上、参考になれば幸いです。

    本フォーラムは、ユーザー(開発者)同士で情報交換を行うためのコミュニティです。初めて利用される方は、以下のアナウンスをご覧ください。 https://social.msdn.microsoft.com/Forums/ja-JP/ca9ecfb7-4407-4fcb-b8bd-207d68257e68?

    2016年10月4日 15:23
    モデレータ
  • 独自の変換関数?なんで? DateTimeの拡張メソッドにして、ついでに拡張メソッドだけ集めたプロジェクトを作っておけば、今回は苦労かもしれないけど、次回から楽やん。

    Jitta@わんくま同盟

    2016年10月4日 22:27
  • 「非推奨だけどそれが回答です」って。。。

    まぁいろんな事情があっての廃止決定なのだな、とそこはわかりましたけどね。

    佐祐理さん
    私の主張が筋違いだと証明するために、歴史まで持ち出してきましたか。
    構いませんよ。経営方針でも企業理念でもコンプライアンスでも、なんでも持ち出してください。

    ひらぽんさん
    提案したとして、「でもそれを検討するかどうかはぼくちんの気分次第だからそこんとこよろしくねー」となりそうで意味ないなぁ。
    それに将来的にというより、今ほしい機能なので…。

    あ、魔界の仮面弁士さんの回答はわかりやすく参考になりました。ありがとうございました。

    2016年10月4日 23:45