【Note】WPF 実行時に XamlParseException、対象が App.xaml 追加の Resources.resx [WPF]
WPF でリソース ファイル Resources.resx を使用すると、以下のような実行時例外がスローされることがあります。
型 'System.Windows.Markup.XamlParseException' の初回例外が PresentationFramework.dll で発生しました
追加情報:'一致するコンストラクターが型 '<リソース クラス名>' に見つかりません。この型は、引数または FactoryMethod ディレクティブを使用して構築できます。' 行番号 '<行>'、行位置 '<列>'。
使用方法が最小限であると、心当たりがなくて詰んでしまいます。
<Application x:Class="<クラス名>"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:properties="clr-namespace:<プロパティ名前空間>"
StartupUri="<開始画面 xaml>">
<Application.Resources>
<properties:Resources x:Key="resources" />
</Application.Resources>
</Application>
この場合、実行時例外のメッセージから見て、引数なしのコンストラクターが単純に見つかっていないようです。
リソース ファイル Resources.resx.cs の自動生成コードでは、アクセス修飾子が public でも、必ず internal のデフォルト コンストラクターが作成されます。
internal Resources() {
}
ビルドの直前に、これを手で public に書き換えてしまいましょう。
public Resources() {
}
こうすると、実行時例外がスローされなくなります。
なお、このコンストラクターは、リソース デザイナーで Resources.resx を保存（書き換えではない）すると、自動的に修飾子が internal に戻ります。
一旦 public で実行できるようになったプロジェクトは、以後 internal に戻っても、クリーンしない限り冒頭の実行時例外を回避することができます（リビルドでも大丈夫）。
プロジェクトをクリーンしてしまったら、上記の手順でもう一度コンストラクターを一時的に public に書き換えてビルドし、改めて internal に戻しておきます。
現象から見て、リソース ファイルのソースコード自動生成部と、XAML パース部との間で、リソース クラスのコンストラクター修飾子に関連する不整合があるような気がします。
いずれ詳しく追跡して、例外をスローする原因を含む中途生成ファイルの特定と、こうなってしまう根本的な原因を解明してみようと思います。
【Tips】iPad で select.onchange 中に alert や confirm でフリーズする問題を回避 [iOS]
iOS 7.0.2 に見られた厄介な不具合の回避方法です。
iOS 7.0.2 Safari Mobile では、select タグの onchange イベントハンドラー内で JavaScript の alert や confirm を実行すると、ユーザーが応答した瞬間にフリーズします。
この問題を回避するには、alert や confirm を select.onchange イベントの期間の後で実行します。
まず select.onchange イベントハンドラーでタイマーだけを仕掛けてイベントから抜けておき、タイマーイベントで alert や confirm を実行したい処理を起動するようにします。
$(function() {
$("select[id='id']").bind("change", null, function() {
setTimeout(function() {
if (confirm(message)) {
...
}
else {
...
}
}, 100);
});
});
タイマーイベントが発生する前のなんらかのコンテキストをタイマーイベントハンドラー内の処理で取得したい場合には、クロージャを活用すると便利です。
なお、この不具合は iOS 7.0.3 でフィックスされたそうです。
【Tips】iPad でポップアップの window.onunload 代替え処理を実装 [iOS]
個人的には Web システムで window クローズ系イベントをトリガーとする処理は実装しない方がよいと思いますが、仕事上で改修の必要に迫られたので調べてみました。
iPad に搭載されている Safari Mobile では、window.onload や window.onunload イベントが発生しません。
ロード時には代替えイベントがあるし、ポップアップ（window.open で開いたウィンドウ）でなければアンロード時の代替え方法もあるんだけど、ポップアップのアンロードではちょっとハマりかけました。
window.onpagehide は来るタイミングが遅いし、body.onunload は来ませんでした。
JavaScript でクローズ処理が書けるなら、以下の方法が使えるようです。
$(window).bind("pagehide", null, function() { /* イベント処理 */ });
・・・
window.open("about:blank", "_self").close();
ブランクで window のアンロードを発生させることで、期待通りのタイミングで onpagehide イベントを発生させる…という流れですね。
しかし残念なことに、Safari Mobile タブ上の × ボタンでクローズされると、この実装は役に立ちません。
【Tips】jQueryセレクターで複数のセレクター属性を指定する [jQuery]
ネット上であんまり情報を見かけたことがないので、Tips として掲載します。
jQuery セレクターでは、セレクターに抽出させたい情報を文字列で記述しますが、この際に複数のセレクター属性を設定できます。
以下の例では、class 属性が "myclass" のチェックボックスをすべてチェック状態にします。
$("input[type='checkbox'][class='myclass']").attr("checked", "checked");
マークアップが煩雑化している古い Web システムの保守をするときに、重宝しています。
【Tips】構成ファイルから TraceSource の名前を動的に取得する方法 [.NET Framework]
.NET Framework でロギングを行うのに重宝するのが TraceSource です。
通常は構成ファイルに記述した名前をコンストラクターに渡してインスタンスを作るんですが、トレースソース名の指定にリテラル文字列を使いたくないので、構成ファイルから動的に名前を取ってみました。
以下、そのソースです。
// get TraceSource name(s) from Configuration File.
Func<IEnumerable<string>> tsnames = () =>
{
ConfigurationSection section =
(ConfigurationSection)
ConfigurationManager.GetSection("system.diagnostics");
PropertyInformation sources =
section.ElementInformation.Properties["sources"];
ConfigurationElementCollection elems =
(ConfigurationElementCollection)sources.Value;
return from ConfigurationElement elem in elems
select (string)elem.ElementInformation.Properties["name"].Value;
};
このようにしておくと、ローカル上で完結できるので、クラスの中を汚さずに済みます。
また、戻り値を IEnumerable<string> にしておくと、実際に TraceSource のインスタンスを作成するときに楽ができます。
Collection<TraceSource> tss = new Collection<TraceSource>();
foreach (string tsname in tsnames()) tss.Add(new TraceSource(tsname));
上記は Windows.Forms ですが、Web にも流用できます。
しばし不定期更新のお知らせ [余談]
◆しばし不定期更新のお知らせ
本業がめちゃくちゃ忙しくなってきました；；；。
仕込んでいた下書きも、正確性が担保できたものについては、使い切ってしまいました。
いくつか下書きが残っていますが、まだ内容が不足していたり、エントリー内容の正確性の担保が取れていなかったりします。
ということで、しばし不定期更新になりそうですが、ご容赦ください。
以上、「しばし不定期更新のお知らせ」でした。
今後とも、よろしくお願いいたします。
Document（HTMLDocument） [JavaScript]
◆Document（HTMLDocument） クラス
JavaScript の Document（HTMLDocument） クラスは、ウィンドウ内外のドキュメント（文書）インスタンスを制御します。
ウィンドウであれば、それがきちんとした画面だろうと、ダイアログだろうと、そして準備されているだけで表示されていないウィンドウであろうと、その Window（DOMWindow） クラス インスタンス window のプロパティ document として、必ずそのウィンドウ用の HTMLDocument クラス インスタンスが存在します。
以下には、そのメンバを機械的に抽出した結果を、インデックスとしてまとめてあります。
調査対象のブラウザは、Internet Explorer 8、Firefox 3.6.13、Opera 11.00、Safari 5.0.3、Google Chrome 8.0.552.224 です。
５つほど、お断りです。
１）長いです
機械的にメンバを抽出してみたら、２１３ありました。
これを全部羅列してるので、長いです；；；。
２）これで全部のメンバを網羅できているとは限りません
機械的にメンバを抽出したんですが、当然あるべき toString などが見当たりません。
従って、これで全部のメンバを網羅できているとは限りません。
３）全部調べるつもりはありません
２１３もあるとは思いませんでした。
全部調べていたら、ひとりで調べてる間に死んでしまいそうです；；；。
４）プロパティ、メソッド、イベントが混在しています
このインデックスでは、プロパティ、メソッド、イベントが混在しています。
この点については、掘り下げていくうちに、整理したいです。
このインデックスでは、HTMLDocument クラス インスタンスを機械的に調査しました。
俺の中では、Document クラスと HTMLDocument クラスは異なるものと認識しています。
この点については、掘り下げていくうちに、インデックスを分けるかもしれません。
なお、よく使うメンバや、定型処理などについては、長くなるので別エントリーにまとめます。
それでは、参ります。
Window（DOMWindow） [JavaScript]
◆Window（DOMWindow） クラス
JavaScript の Window（DOMWindow） クラスは、ウィンドウ インスタンスを制御します。
ウィンドウであれば、それがきちんとした画面だろうと、ダイアログだろうと、そして準備されているだけで表示されていないウィンドウであろうと、必ずこの Window（DOMWindow） クラス インスタンスが、ひとつ以上存在します。
以下には、そのメンバを機械的に抽出した結果を、インデックスとしてまとめてあります。
調査対象のブラウザは、Internet Explorer 8、Firefox 3.6.13、Opera 11.00、Safari 5.0.3、Google Chrome 8.0.552.224 です。
５つほど、お断りです。
１）長いです
機械的にメンバを抽出してみたら、５１５ありました。
これを全部羅列してるので、長いです；；；。
２）これで全部のメンバを網羅できているとは限りません
機械的にメンバを抽出したんですが、当然あるべき toString などが見当たりません。
従って、これで全部のメンバを網羅できているとは限りません。
３）全部調べるつもりはありません
５１５もあるとは思いませんでした。
全部調べていたら、ひとりで調べてる間に死んでしまいそうです；；；。
４）プロパティ、メソッド、イベントが混在しています
このインデックスでは、プロパティ、メソッド、イベントが混在しています。
この点については、掘り下げていくうちに、整理したいです。
このインデックスでは、Window クラスと DOMWindow クラスが混在しています。
正直、Window クラスと DOMWindow クラスでは、ちょっと差が大きいです。
この点については、掘り下げていくうちに、インデックスを分けるかもしれません。
なお、よく使うメンバや、ライフサイクルなどについては、長くなるので別エントリーにまとめます。
それでは、参ります。
@OutputCache [ASP.NET]
◆@OutputCache ディレクティブ
<%@ OutputCache Duration="#ofseconds"
Location="Any | Client | Downstream | Server | None |
ServerAndClient "
Shared="True | False"
VaryByControl="controlname"
VaryByCustom="browser | customstring"
VaryByHeader="headers"
VaryByParam="parametername"
CacheProfile="cache profile name | ''"
NoStore="true | false"
SqlDependency="database/table name pair | CommandNotification"
%>
ASP.NET Web フォームや、ASP.NET Web フォーム内に含まれるユーザー コントロールの出力キャッシュ ポリシーを制御します。
詳細なリファレンスは、MSDN の公式ヘルプを参照してください。
このディレクティブは、使いどころがあります。
･･････てか、そもそも ASP.NET の根本の挙動がおかしいから、期待通りの挙動をさせるために、こいつでキャッシュを殺さなきゃならない、なんていうケースもあるわけで。
能動的に使えるケースと、こいつを使う必要に迫られるケースと、まあいろいろと事情があるんですが。
@PerviousPageType [ASP.NET]
◆@PerviousPageType ディレクティブ
<%@ PreviousPageType attribute="value" [attribute="value"...] %>
ASP.NET Web フォーム（.aspx）で、遷移元のページと遷移先のページが決まっている場合、遷移先のページで指定できます。
TypeName 属性か、VirtualPath 属性を使って、遷移元の ASP.NET Web フォーム（.aspx）の、「厳密な型指定」ができます。
遷移先の ASP.NET Web フォーム（.aspx）の Page.PreviousPage プロパティに、このディレクティブで指定した「型」が適用されます。
詳細なリファレンスは、MSDN の公式ヘルプを参照してください。
･･････てか、必要なの？ こんなディレクティブ。
みみちゃん さん
-
nice! 116
記事 47
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
