A way to avoid that ?
-
Oh, that's interesting.
Couple a thoughts - terminate the message with a c language null: '\0' (just in case?) The size should still be 2048 including the null.
More obviously, you don't need to peek every loop iteration - so something like:
refresh if (loop_counter % 500 == 0)
-
@jim said:
Couple a thoughts - terminate the message with a c language null: '\0' (just in case?)
Isn't that just for strings?
The string I pass is just a data buffer that will be filled with binary data - which one has to extract.@jim said:
More obviously, you don't need to peek every loop iteration - so something like:
refresh if (loop_counter % 500 == 0)Yes - more pragmatic than calculating time. I like it, it's KISS.
-
@thomthom said:
Isn't that just for strings?
Yeah, I made an assumption the message was a c character array.
-
@jim said:
@thomthom said:
Isn't that just for strings?
Yeah, I made an assumption the message was a c character array.
No, it's a MSG structure. Just didn't bother to work out exactly how large it is. (probably will be making a wrapper for this.) So I just make a large buffer while I quickly tested it.
...if I don't need the returned message, would it be ok to just send an empty buffer? -
@dan rathbun said:
@thomthom said:
Yes - as long as the operations a kept small it'll prevent whiteout.
"whiteout" = "ghost window"
...[snip]...
I would attempt to force a [PeekMessage](http://msdn.microsoft.com/en-us/library/ms644943(v) system call, for Sketchup's thread, within the "responding inteval" (can't remember offhand what it is.)
So any way it's not your add entities block that needs to go inside a UI.start_timer proc, ... it's a API call to PeekMessage, like:
begin > peek = UI.start_timer(interval, true) { > peek_window_msg() > } > do_create_lots_of_model_entities() > UI.stop_timer(peek) > end
where, peek_window_msg() would be a method that sets up and makes the proper API call.
@ThomThom & friends, ... I stumbled across where I saw the 'whiteout' interval.
It's specified on the [IsHungAppWindow](http://msdn.microsoft.com/en-us/library/ms633526(v) Function reference page.
Says 5 seconds.So perhaps:
begin interval =( Sketchup.version.to_i<8 ? 4 ; 4.9 ) peek = UI.start_timer(interval, true) { peek_window_msg() } do_create_lots_of_model_entities() UI.stop_timer(peek) end
-
Interesting - from that article.
@unknownuser said:
An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not called PeekMessage within the internal timeout period of 5 seconds.
Though, it seems one can't reply on that time.
@unknownuser said:
The Windows timeout criteria of 5 seconds is subject to change.
I have set the interval to a handful of times per second because I use it to force SU to update its statusbar.
-
I still wonder if a peek message loop could be written into the
commit_operation
API method. -
And there is another 'nutty' thing that happens. When the ghost window is created, it has a different handle then the "real" application window. There are a couple functions that return the other handle, depending on which window handle you grab. (Strange that the IsHungAppWindow function is "not for general use.")
-
@dan rathbun said:
I still wonder if a peek message loop could be written into the
commit_operation
API method.I made a wrapper iterator that will take an enumerator objects and wrap it in between start and commit operation while updating the progress in the statusbar, kept alive by PeekMessage limited to a certain interval. Works really well for simple one-iteration operations.
-
Update for Sketchup 2014 :
require "Win32API.rb msg = "\000" * 36 peekMessage = Win32API.new('user32','PeekMessage' , 'PLIII', 'I') peekMessage.call( msg, 0, 0, 0, 0x0000 ) != 0
Advertisement