Win32API質問箱 Build36

Windows付属のペイントの減色処理がしょぼすぎなだけなので普通はgifが使える。

>>951
スルーされたかったのに妄想厨に絡まれたんだよヽ(`Д´)ﾉ
どうせ2chの書き込みは全部漏れの自作自演だよヽ(`Д´)ﾉ

>>1-1000
自演乙

オマエモカ！

オマエモダ！　　　　　　　　　　　　　　　　　　　　　　　　　　( ﾟдﾟ )

CでWin32APIを使用しWindowアプリケーションを作りたいのですが、
C++の知識は必要でしょうか？

Cで作るのにC++の知識がいるかボケェ

でもCOMまわりはC++できないと辛いお

どこもC++については意見が真っ二つですよね・・・

COM使わにゃえぇだけ

作りたいアプリによると思う。

なんでも全部自分でやるならCだけで充分
でも人が作ったものを利用しようと思った時にC++知らないと不便だろ

なるほど・・・
日曜プログラマーの延長線進もうとする自分にとっては
微妙なようで・・・

驚いた、人の作ったC関数ライブラリ使うのにC++知らないと不便なのか

まぁ、先にC++覚えたほうが後々楽できるとは思うがそこは人それぞれだな。
俺はもう素のCなんか書きたかねーが。

そこがプロとアマの違いｗ

わたしゃ日曜プログラマですが、C++覚えた方が色々と楽な気がする。
Cで書いてた時よりも遙かに楽になった。

C++思考ができれば、な

なぜかGetClipboardDataが失敗するのですが。
GetLastError()は、ERROR_CLIPBOARD_NOT_OPENです。

確かにちゃんとOpneClipboardが成功しているのですが。

EmptyClipboard()やSetClipboardData()はできるようです。

現在時刻をミリ秒かマイクロ秒単位で取得する関数はありますか。

進んでみて駄目/必要そうなら++を学習してみます。
本当にありがとうございましたm(_ _)m

timeGetTime, GetTickCount(ms単位)
QueryPerformanceCounter (QueryPerformanceFrequency単位)
GetSystemTimeAsFileTime(0.1µsec単位)
ただし、実際に器の単位で時刻が進むとは限らないはず。

つーか、そもそもPCのRTCにそこまでの精度がないからやるだけ無駄。

ネットワーク共有のフォルダをFindFirstFile、FindNextFileで列挙しましたが、
2000個のフォルダを列挙するのに８秒ほどかかります。
ローカルでやると、100msくらいなのですが、なぜこれほど
ネットワーク越しは時間が掛かるのでしょうか？

離れてるから

>>973
へぇ、timeGetTimeって「現在時刻」だったんだ

最初に別の方法で時刻とタイムカウンタの値を取得しておいて、
あとはタイムカウンタの差分を取得しておいた時刻に足せば、
現在時刻になるわけだが。

>>978
それは別の方法の精度が悪ければいくらタイムカウンタの精度が良くても意味がないだろ。

>>978
「現在時刻をミリ秒かマイクロ秒単位で取得する関数」なんですか？ｗ

論点違ってんだよ

現在時刻が1970/1/1からの秒数であるか、1601/1/1からの
0.1µsecであるか、システム起動時からのmsであるかに
そんなに大きな違いはない。

結論としては1ms単位での取得は無理。
中身どうなってんのか俺は知らんけど、
そもそもＯＳ側でのタイマの更新がそう頻繁に行われて無いと思われ。
今、タイマ関数を読んでその値が一体何時に取得した値なのか1ms単位ではわからないんではないか？と予想。
経験だとだいたい20ms単位ぐらいなら文句が無い程度には動く。

マルチメディアタイマーを使えばもっと細かい時間が
取得できるとかどっか書いてあったけど？

理論上はな
実際と理論は違うのだよ

>>983
そもそもWindows自体が全てがメッセージで動いてるわけで、
タイマのときだけメッセージ無視して早く動くとも考え難いじゃん。
Windowsってさ、だいたいが、その状態があってそれを取得するのは早いけど
ひとたびハードにアクセスするってーとかなり時間がかかると思うんだがどうだろうか？
だからタイマ取得関数ですぐレスポンスが帰ってくるのはそもそも俺が関数を呼び出す
もっと前に取得しておいたものだと俺は考えるわけだがどうだろうか？
だから時間は関数を呼び出す前からすでにずれていると思うわけよ。
はじめに設定する精度ってのはWindowsがとってくるように
努力しようとする周期（実際にとれているかどうかは問題では無い：まあ、期待値ｗ）であって、
メッセージで動くWindowsにそもそもそんな周期での仕事は無理なんじゃねぇの？
ってのが俺の予想。

窓上でそんな時間取得できるのか？
普段のもっさり感考えるとかなりばらつく気がす

そもそもメッセージはみなのんびりゲットしてる

マルチメディアタイマーは割り込みじゃないのかなー

http://www.emit.jp/prog/prog_t1.html
timeBeginPeriodを使えばGetTickCountの精度まで良くなるそうだ。

Win32API質問箱 Build37
http://pc8.2ch.net/test/read.cgi/tech/1131884991/l50

8254叩いて今の値をとってくるのに、そんなに時間は掛からないとおもうが。

>>988
割り込む処理もメッセージだったら？

>>989
>記事の行数が増えてしまうので NT(2000) での結果は割愛しましたが、精度は 10mSec でした。(^_^;
これはなぜか？
って考えないのかな？。
つまり、NT系に当たるXPもこんなもんじゃねーの？

>>992
もしメッセージだったら精度は悪くなるだろうね。
実際はメッセージじゃないけど。

回答者は憶測だけで書き込むのはやめろ。
マルチメディアタイマは最優先度のスレッドが生成されそのスレッド内でループする仕様。
Win32APIに割り込みなど存在しない。

>>995
スレッドならメッセージでやりとりするしかねーじゃん。

この時間帯、書込みのレベルが低いな。>>996みたいな天然の初心者が多い。
口調が初心者風でないだけにムカつく。

>>993
シングルプロセッサのNT系のクロック割り込みが10ms単位らしいから、
タイマーの精度もそれに依存してるって話では。

タイマーのOS内部での動作としては、クロック割り込みがくるたびに、
システム内のカウンターに割り込み間隔分の値を加算していく。
timeGetTime()とかGetTickCount()とかは基本的にこのカウンタを返してるだけだから、
精度はクロック割り込みの設定に依存する。
（基本的にはどのOSでもこのへんの構造は大差ない）

QueryPerformanceCounter()は、クロック割り込みとは別のハードウェアを使ってるから
（使える環境なら）より精度の高いカウンタとして使える。

マルチメディアタイマーは割り込みじゃなくてコールバック。
詳しくは知らないが、>>995みたいなビジーループ回してるんじゃないかな？

>>997
で、あなたの反論は？

　　　　　　　　　　 ∩＿
　　　　　　　　　 　〈〈〈　ヽ
　　　　　　　　　　〈⊃　　}
　　 ∩＿＿＿∩　 |　　 |
　　 | ノ　　　　　 ヽ !　　 !
　　/　　●　　　● |　　/
　 |　　　　( _●_)　 ミ／ ＜こいつら最高にアホ
　彡､　　　|∪|　　／
/　＿＿　 ヽノ　/
(＿＿＿￣＼　/
　　　　（_ﾉﾉﾉ│
　　　　　　　∪

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。