GradientStopCollection
は、保存された文字列から作成する非常に便利な方法があります。しかし、それは入力のために何が期待されているのかどこにも書かれていない。 MSDNは約unbelievable laconicです。 最初の直感的な考え方は、逆のToString()
メソッドが返すものを使用することです。シンプルな形式を示しています(例:#FFFFFFFF;1 #FF0000FF;0,25 #FFFF0000;0,5 #FFFFFF00;0,75 #FF000000;0
)。しかし、その文字列を解析しようとすると、「トークンは有効ではありません」という全く知らないエラーが発生します。GradientStopCollection.Parse()の形式ですか?
私はGoogle以外の誰もがその方法を使用していることを認識していません。奇妙な。 私はsource code of that methodを見つけましたが、それは私が理解するにはあまりにも "内部"です。
もちろん、同じ文字列を同じLINQクエリで手作業で解析することはできますが、それは私の今のところの原理のように、動作する方法を理解することです:)また、コードが少なくて済み、別の自転車を再発明する。
だから誰もその方法を使ったことがありますか、ソースからどのようなフォーマットが期待されているのでしょうか?ソースあなたが言及したコードとTokenizerHelper Source Codeを読んだ後、私が言うことができ
ありがとうございます。出力と入力の形式が何の説明もなく違うのは奇妙ではないですか? Btw、そこにどのような文化の依存関係がありますか?私は一度完全に動作していた私のアプリケーションを覚えているので、入力された小数点区切り文字を解析することは、システム設定の小数点区切り文字が異なるため、 –
@WolfrevoCats 'IFormatProvider formatProvider = System.Windows.Markup.TypeConverterHelper.InvariantEnglishUS'のため、私はその文化に依存しないと思います。 –
これは信じられないことですが、 'Parse()'メソッドが文化依存でない場合でも、逆のToString()は!私はちょうど、現在の文化が米国に設定されているPC上の私のアプリにバグを捕らえました。そして、上の例の私の勾配の文字列表現は、 '#FFFFFFFF、1#FF0000FF、0.25#FFFF0000,0.5#FFFFFF00,0.75#FF000000,0 '!これは解析することができます。 これを考慮すると、私は明らかにこれらの方法のカップルの実現にバグを見ます。最初のものは現在の文化を使用し、もう1つはEnglishUSに固定します。彼らは今オープンソース化されているので、.NETコミュニティにバグを投稿すると思います。 –