2020年10月31日

室温記録は飽きたので、車の中の温度ログを取っていたこの2か月

9月24日のお昼に最高温度:55度を記録しました。

温度計は、リアシート裏(ヘッドレスト裏)に貼り付け
平日昼間は会社、週末と夜は自宅に車がある。

お昼は会社の駐車場(いつも同じ場所)。
リア側が南を向く。なので最高温度はここで記録されたものだろう。

2020-10-31_220721.png

やっぱり車内は熱くなる。

徐々に気温が下がってきていることもよく分かった。

最高温度が高くならない(おそらく日差しが強くない)ところでは、Humidity (青のグラフ:湿度)が高い傾向にあるね。

出勤、退勤の時刻あたりにスパイクがあるので、勤務時間管理にも使えるな、これ。(一日を拡大してみてます)

@2020/10/31 22:14 | Comment(0) | くるま・車

2020年10月25日

モバイルSuicaを新しいアイフォーンに移動する方法

【機種変更】iPhone/Apple Watchから、別のiPhone/Apple Watchへ。 | Suica Apple Pay よくあるご質問

すごく簡単だった。

2020年10月19日

たったの一文字:$  自作のエクセルマクロが会社のWindows Defender でマルウェア扱いしてきたのだが、ようやく解決した

とにかく、ブロックされるたびに
その検知メッセージを見ながら「きっとこういう処理が検知されるんだろうな」というところを
検知されにくくなるように対処してきた。

###2020・11・1時点、結局は会社でのDefender誤検知は防ぐことができました。
でも自宅でそのマクロを実行すると 検知されブロックされてしまいます。自宅のWindowsのほうが新しいビルドだから?よくわからん。とにかく不毛な鼬ごっこのような気がするので自宅でのDefender誤検知対策は、コードの修正ではなく、ひたすら Microsoftに「これは誤検知だよ」と言い続ける作戦に変更しましtあ。
###

以下の画像はブロックされたタイミングで「自分が作ったマクロなんだから 許可!」とやった後の図です。
(最終的には許可はすべて取り消しました。問題を放置することにつながるので)

2020-10-19_205605.png

2020-10-19_204127.png

2020-10-19_204105.png

それでも、やっぱりブロックされ続ける。
でも、もう想像の範囲内では怪しい処理は書き換えた。直すところが分からない。。。。。

そこで最後に、「いったいどこが検知対象なのか」ということで割り出した結果以下の対応をしたところ、マクロのブロックがぴたりと止まった。
RTrim()関数 を RTrim$() に変えた(1か所)
さらに、この怪しい記述は コメントアウト ' していようがそこにあるだけでブロックされた。
'怪しいAPI宣言なども コメントアウトした文字列が残っているだけでNGである。

理由はわからないが、実際に怪しいマクロではなくても、コメントの有無だけでもブロックされることがあるという事が分かった。

なぜこれが ブロックの対象になったのか全く分からなかった。でも問題の個所はこれさえ直せばこれまでブロックされていた複数のPCでブロックされる事態はすべて解消したのだから、現時点の解決策としてはこれで間違いがない。

いつもマクロのリリース(仕上げ)に
http://cpap.com.br/orlando/VBADecompilerMore.asp
を使っているんだけど、こいつが悪さをしているんじゃないかと疑っていた時もありました。でもこいつは関係がなかった。(このツールは余計なバイナリをそぎ落としてコンパクトサイズにするのに使っています)。
会社のWin10-1909 だと問題ないんだけど、最新の2004だとVBADecompiler.exe ででコンパイルしたモジュールができたとたんに削除されてしまう。やっぱりこいつは危ないみたいだ。



怪しいコードの割り出しをするために以下の方法で行いました。
・VBAのソースコードをすべて出力しておく
・新規のマクロブックを作成し、ソースコードを1ファイルずつ取り込んでは「保存」をする
※ Defenderがブロックするタイミングは、「保存」の時だけです。おそらく VBAを保存したときに内部的なバイナリコードを生成していて、これがサーチ対象になっているっポイ(つまり、動的挙動のサーチではなくて、静的な解析をしてるんだね)。

・ここでブロックされたファイルがあった場合、そのファイルを覚えておき、次のファイルの取り込みをする。最後のファイルのインポートまでを行う。
※ 途中でコンパイルをする必要はありません。あくまで ソースコードの取り込み⇒保存 を繰り返す。

・ブロックされたファイルの 一部だけを取り込み「保存」をします。一部というのは、変数宣言、関数プロパティなど、固まりのある範囲。これらも、コンパイルが正常に行われるかどうかを確認する必要がないのでとにかく、「ブロックされたファイルの上半分」とか、そういうくくりでいいので 内容をくくりだして、マクロを保存してチェックします。
・これによって問題の関数が絞り込めるまで、行います。ファイルを割り出したときと同様、問題のある関数だけ控えておいて、それ以外の関数などは全部マクロへ保存します。


・問題の関数が絞り込めたら、関数の中のステップの一部を保存し、同じように問題の行を割り出します。

・問題の行が分かったら、そこから先は何かひらめくまで試行錯誤します。
 無くてもよいステップか、書き換えはできないか?と自問自答する。
※ 私の場合は Rtrim()を Rtrim$() に書き換えてみるという事で解決するという「発見」をしました。
 そのほかにも、WshShellで Copy,Move,Delete,CreateShortCut などを行うと アウトのようです。まあ、つまりマクロでファイル入出力を行っている痕跡が検知されるとかなりの確率で ブロックですん。

今後どうなるかわかりませんが、現時点のDefender対策として書き留めておきます。
※できるだけ複数のWindowsで検証されることをお勧めします。 悪意のない普通のコードを書いているとしても、お構いなしに理不尽な理由(場所)でブロックされるという事が良くわかりました。(コードそのもののお行儀が悪そうな場所でブロックされるという事は私の観測内では0件でした)

マクロコードの64Bit環境対応もできたし、こっちのめどもついた!!

先輩の家に行ったら『会社員っつーのはオンとオフの切替が必要なんだよ!わかるか!?出勤したらオフ!退勤したらオン!なんだよ!』と言って部屋のミラーボールの電源入れ始めた - Togetter

#マクロブロックされる傾向が一つ分かった#
マクロ付きブック(XLSM)形式で何の問題もなく保存できるものでも
アドイン(XLAM)形式で保存すると、ブロックされることが分かった。
 同じ基準でブロックしてくれよ、、、

2020年10月16日

Sysinternals Suite Updated [Sakura's VPS auto Post]

Sysinternals suite(zip) may be updated.

Current Timestamp
2020-10-16 06:54:08.000000000 +0900 ,37381833 bytes
Before Timestamp
2020-09-18 09:17:47.000000000 +0900 ,36662476 bytes

Check Official web site !
Directe Link (SysinternalsSuite.zip)
Search Old Posts of this Blog.
@2020/10/16 07:07 | Comment(0) | Tools-Sysinternals

2020年10月12日

VBAから .net アセンブリを利用する

VBからCLR(.NET)を利用する その1[準備編] - Programming Field

64bit 環境でも32 Bit環境でも区別なく同じマクロ(アドイン)が使えることに気をよくしたので、さらに欲が出た。
いろいろVBAに機能を足したいがそのためには .net が使えると都合が良い。

2020年10月08日

いつの間にか 64Bit版 VBAへの移植(というかVBAソースコードの32Bit版との共用)は「無理」から「可能」になっていた

LongPtr がいい仕事してるという事が分かった。

Excel2010 以降の環境をターゲットにし、2007より古い環境は切り捨てる、という事でもあるけれども

VBAでWin32APIの64bit対応自動変換プログラムを作ってみた - えくせるちゅんちゅん

数年前まで手持ちの 32Bit版エクセルで動くマクロアドインを同じコードで
64Bit版ExcelVBA環境でも動かそうと、頑張っていた。
その中での一番の強敵は Win32APIの64ビット対応と、あとは MSCOMCTRL.ocx の参照設定である。このOCXが、当時は64Bit版にそもそも存在しなかったのだ。この時点であきらめていたんだけど。

2020年の今、それらは64Bit版にも用意されている。

そこで重い腰を上げ API対応に取り組んでみると、意外と簡単。これまで 条件付きコンパイル引数で VBA7 やら Win64やらで切り替えていた(そうするようにおすすめされていた)記述は、全く条件分岐させる必要がなく 1パターンの記述で(だいたいが)対処可能という事が分かった。

非常に大事な資料は Win32API_PtrSafe.txt 。まずは忠実にこのAPI宣言を コピーする。今までいい加減に Long だとか LongLongとか、Boolean とか書いていたところを改める。

Excel2010以降を対象にする限りは、32Bit環境でも PtrSafe宣言は 書いてあっても動く。
しかも LongPtr を書くと、32Bit環境では自動的にLong と解釈される。
つまり #If VBA7 で振り分ける必要がない。

一気に手持ちのマクロを改修した。 置き換えたAPI宣言が 手持ちの定義と違っていて動かなかったところが少しだけあったけど、そういう変な記述を見直すいい機会になった。

確実に64Bit対応するには、Excelを64Bit版導入して、ビルドエラーが出なくなるまで完全に問題を消し込むこと。思い込みで型を書き換えていってもどこかで間違える。

#余談
使用するOSのBit数も64Bit環境であることを前提にできるととても楽ちんだし、
さらにはOSについてもWindows10と決め打ちできるともっと楽だ、
Office2016以降だとするともっともっと簡単だ


・おすすめ楽天ショップ1:trendyimpact楽天市場店
・おすすめサプリショップ:iHerb.com
・おすすめ楽天ショップ2:上海問屋
Powered by さくらのブログ