HSPTV!掲示板

#uselib "winmm.dll"
#cfunc global timeGetTime "timeGetTime"

mes timeGetTime()

なんか数日前　2017/5/10 くらい？　から

Windows が起動してからの経過時間を
ミリ秒単位で返す関数

timeGetTime()がマイナス数値からスタートするような気がするのですが
私の環境だけでしょうか？

数十日、ずっと起動してませんか？

コンピュータを連続で、24.855日稼働していると、マイナス値からのスタートとなります。
これは、数値の扱い方に起因している物で、正常な動作となります。

timeGetTime 関数が返す数値は、DWORD値(0〜4294967295) の範囲です。
HSP が扱える数値は、int値(-2,147,483,648 〜 2,147,483,647) の範囲です。

今日の7時に完全にシャットダウンされていた（はずの）パソコンを
電源ボタンで立ち上げて
その２時間後に　timeGetTime関数を使ったら数値がマイナスだったのです。

もともと昨日、１５時間連続稼働のパソコンでtimeGetTime関数を使ったら
その数値がマイナスだったのでこれはおかしいなと思ったのが始まりなんですが…

ただ、今パソコンを再起動してすぐにtimeGetTime関数を使ってみたら
2430296　だったので正常なんでしょうね。

OSはwin8.1で毎日ウィンドウズボタンからシャットダウンしているのですが…

とりあえず様子を見てみることにします。
アドバイスをくれた方に感謝します。

あーWindows 8.1か。通常のシャットダウンと完全シャットダウンのお話である。

通常のシャットダウンはWindows 8からシステム周りはサスペンドという仕組みになっている。
再起動をすると完全シャットダウンから再起動を行うのでリセットするが、
シャットダウンを選択すると通常シャットダウンが行われ、システム周りのデータはサスペンドされる。
このサスペンドデータによってtimeGetTimeの値が保持されているため、起動したばかりでも大きな値が出る場合がある。

という話が他のところで議論されてた。
https://www.activebasic.com/forum/viewtopic.php?f=1&t=4573

Velgailさんのご指摘がズバリですね。

timeGetTime関数を使ってソフトを作るときは
環境によってマイナスが返ってくることも視野に入れないといけませんね。

まあ、ぶっちゃけて言うと、時間差分を取っている場合、2週間以内の差分であればマイナス値であろうと安定的に計算できます（正確には24日程度？　上のコメントを信用すると

これを実行してみればわかります。

mes (-2147483640) - (2147483640)

結果：16

実際に次のようなコードで検証してみましょう

a=2147483640
repeat 16
a++
loop
mes a

結果 -2147483640

このように単に循環しているだけなら計算に支障をきたさないので、ある程度(差分が21億を超えない範囲)まで無視できます。