先日、お客様から連絡があり、古いPC-98のパソコンが壊れて動かなくなったとのこと。

症状を聞きながら色々と試して貰うと、HDDは大丈夫なようで、別の使っていないPC-98にHDDだけ入れ替えてソフトが起動できるようになりました。

OSがWindowsではなくMS-DOSで、もう20年くらい前のソフトを今も使っているようです。

今回は使っていないパソコンが余ってたので良かったですが、またいつ壊れるか分からない危険な状態です。

特注の検査装置のソフトなので、簡単にパソコンを更新する訳にもいかないのは分かるのですが、問題が発生したときのリスクを考えると、数年単位に更新の検討をするべきだと思いました。

開発側も更新時期をお客様に提案し、危険を回避できるように動いた方が良さそうです。

M社製2軸サーボの同期制御を行いました。
問題は2軸の負荷に65kgの差があることです。
個別のゲイン調整では高速回転時にズレが生じてしまいます。
ポイントは負荷の小さい方のゲインを負荷の大きい方のゲインに合わせるところです。
これは、最終的な負荷状態でないと調整できないので結構緊張します。
⇒完成状態でぶつけると誰も許してくれませんから・・・
また、一案件に一回の調整なので手順書などを作っておかないと次回の調整で思い出せません。
最終的には最高回転数で実現在値の誤差を±１パルスまで追い込めました。
あらためて日本のサーボ技術に関心しました。

MGCです。

秋が本当に来ていたのかと感じさせるぐらい急に冷え込みが激しくなってきました。
寒さには弱いので早々からコートをおろしてしまいました。
ただ四季の中で冬が一番好きなのですが。

最近博多の駅前が陥没したというニュースを目にしました。
工事にもどれほどの時間がかかるのやら、、と思っていたのですが、
流動化処理土と呼ばれるセメントと土砂を混ぜた特殊な土を使用して
復旧工事を行ったそうで、
1週間で完全に復旧していました。
日本の底力には驚かされました。本当に素晴らしい。

mtjです。

WindowsFormで実装していると謎のエラーが発生する時があります。
表題の通り、クラシックと通常モードでWindowsFormの動作が変わるものもその一つです。

自分たちでテストしているときはクラシックにしないので何も発生せず、お客さんのところで運用している
間にクラシックで問題発生とのことが起こる場合があります。

原因はクラシックではFormが表示されていない（コンストラクタ内）にもかかわらず
一部イベントが発生するためです。
Formのコンストラクタ内部で初期化したとしてもデザイナーでnullが入る可能性もあるためなかなか把握できません。

一番簡単な方法で先で全てnullチェックをするのが確実な方法だと思われます。
またはCreatedプロパティがあるのでそれがtrueなら処理を行うが一番確実だと思われます。

上記の問題はログを確認してもなぜNULLが入っているのかわかりにくい点が厳しいです。
スタックトレースを見ればInitializeComponent()から発生しているのですぐわかりますが。

今仕事でWPFを使用しています。

いつも仕事ではWindowsFormを使用しており、馴れているためWPFに移行出来ていませんでした。

実際使用してみると一長一短ではあるものの、今後はWPFでも良いかと思っています。理由は以下。

１．予想よりも移行が簡単である。もっとWindowsFormとのギャップがあるかと考えていたが、それほどでも無い。事前にXAMLやVMMVを理解していたからかもしれないが。

2. 予想よりもWindowsFormと共存ができる。いままで社内ライブラリで使っていた共通のWindowsFormがWPFのプロジェクトで使えたり、WindowsFormsHostコントロールを使用してWindowsFormコントロ－ルが使えたり。

3.自由度が高い。さすがWPFと思えるところ。今まで簡単にできなかったことができるようになる。逆に今まで簡単にできたことが多少面倒になっている部分もある。

4.UWPの布石として。 正直、WPFがWindowsFormに置き換わることは無く、その前にデスクトップアプリが無くなりUWPに移行すると思われる。UWPのUIもXAMLなのでWPFに馴れておいた方が良い。