And yeah, mine crashed too. Going to give up for the night on this one. Thanks for helping to test.
dave
It is currently April 27th, 2024, 4:44 pm
second/third screen preview box
-
- Developer
- Posts: 265
- Joined: June 28th, 2014, 8:32 am
- Location: Tokyo, Japan
-
- Developer
- Posts: 22631
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: second/third screen preview box
We were wondering why you are using a #Variable# at all?
Why not have options in the plugin measure just define an "offset" from the current mouse position. Something like:
The suspicion is that it might be kinda unsafe to have something setting variables during Reload(). Not sure I follow why the "skin" needs to know the current mouse position anyway. Really only the "plugin" cares. Seems to me that you are using the #Variables# to tell the plugin something it already knows. And what you are telling it is not "now" but "then" anyway.
I could perhaps see some value in being able to display the current mouse position in a string meter, but at least that would just be "output" and not simultaneously "input and output" for the plugin. I still maintain that having the skin "know" the mouse position can at best only be at a level of accuracy that is "up to Update milliseconds ago" anyway. Marginally useful.
Why not have options in the plugin measure just define an "offset" from the current mouse position. Something like:
Code: Select all
[MeasureScreen]
Measure=Plugin
Plugin=ScreenShot
MouseXOffset=-100
MouseYOffset=-50
ScreenCaptureW=200
ScreenCaptureH=100
OutputImage=#CURRENTPATH#frame.bmp
I could perhaps see some value in being able to display the current mouse position in a string meter, but at least that would just be "output" and not simultaneously "input and output" for the plugin. I still maintain that having the skin "know" the mouse position can at best only be at a level of accuracy that is "up to Update milliseconds ago" anyway. Marginally useful.
-
- Developer
- Posts: 265
- Joined: June 28th, 2014, 8:32 am
- Location: Tokyo, Japan
Re: second/third screen preview box
I think you're a bit confused about how Rainmeter works. Here's what happens for a skin (look in rainmeter/Library/Skin.cpp, in the Skin::Update function):jsmorley wrote:I still maintain that having the skin "know" the mouse position can at best only be at a level of accuracy that is "up to Update milliseconds ago" anyway. Marginally useful.
- 1.) Wait until Update timer has expired (the time is specified as Update=X in the .ini file)
2.) Get WM_TIMER message from windows
3.) (this part is all inline in the same code)- a.) call Update() for each measure (if dynamic variables, this calls Reload() at the start of Update())
b.) call Update() for each meter
c.) call Draw() for each meter
- a.) call Update() for each measure (if dynamic variables, this calls Reload() at the start of Update())
dave
-
- Developer
- Posts: 265
- Joined: June 28th, 2014, 8:32 am
- Location: Tokyo, Japan
Re: second/third screen preview box
Because then it no longer works as a fullscreen previewer, per the original poster's request. And by exposing the coords to the script you get the flexibility to control them from Lua or another meter. The plugin just needs to do the low-level work of actually grabbing a chunk of screen and writing it out to an image file.jsmorley wrote:We were wondering why you are using a #Variable# at all?
Why not have options in the plugin measure just define an "offset" from the current mouse position.
I still suspect the issue is due to the plugin doing an RmExecute from inside the update. I suspect a cleaner path would be to expose something like RmSkinSetVariable in the plugin API, but it doesn't currently exist and I wanted to try not to hack up the core application if I could avoid it.
dave
-
- Developer
- Posts: 22631
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: second/third screen preview box
Yeah, sorry, I was thinking about this in terms of setting a #Variable# in an IfCondition or mouse action or some other action in the context of the skin, which generally is going to require that you force an "update" of one form or another so it doesn't wait for the next normal update cycle to react to the change.dgrace wrote: There is no possible delay between reading the mouse position in Reload() and doing Update(), Draw() and sending pixels to the hardware.