This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
theoriginalbit's profile picture

2 Suggestions — OS Pull Event (Raw) & Mouse Triggering (don't worry its not an add mouse_up / mouse_down request )

Started by theoriginalbit, 18 February 2013 - 09:36 PM
theoriginalbit #1
Posted 18 February 2013 - 10:36 PM
OS Pull Event (Raw)

Description:

Currently as is stands os pullEvent/Raw are used massively. Now the pulling of specific events is handy too when you provide an argument
os.pullEvent("mouse_click")
now my question/suggestion here is, that when this "mouse_click" event fires it returns these variables:
"mouse_click", <button>, <mouse-x>, <mouse-y>
So seeing that the event that fired is still in there, I had an idea, could it be possible to have multiple arguments so we could use this
os.pullEvent("timer", "mouse_click")
And it would only continue when either of these events has fired. Now I know that this IS doable in CC, as a matter of fact I've helped people do it before with something similar to this

local function wait()
  while true do
    local event = { os.pullEvent() }
    if event[1] == "timer" or event[1] == "mouse_click" then
      return unpack(event)
    end
  end
end
Now the way I understand how CC works, using os.pullEvent("timer"), means that the CC wont even run the computer until that computer gets the timer, which makes it handy if your trying to minimise on the CPU strain and such, using the code I gave above does the exact opposite of this, thats why I think having multiple arguments could be useful as the program still holds until it gets the event, but its 'checking' for multiple events. Now if I'm wrong in my understanding of how CC works then sorry for wasting your time with this one :)/>


Mouse Triggering

Description:

Don't worry I'm not about to go say give us "mouse_up" or "mouse_down", I know its on the do not ask list :P/>

What I'm asking today, is that if the up/down aren't coming in the immediate future, or you end up not being able to find a nice way to do it with the multi-user environment, I ask this of you. Can the way the "mouse_click" event is fired be changed. What I mean is, currently the "mouse_click" event occurs when the mouse is well, clicked. Now when using Windows, OSX, Linux, Android, iOS, Windows Mobile, (….. the list goes on), when you click/tap on something, say a button, the action isn't triggered right away. This gives the user a chance to change their mind and move the cursor away from the button so as to not click that button.

Now currently is seems that CC has it so that when LWJGL gives it a mouse down, it triggers the "mouse_click" event. All I ask, is that if there are no immediate plans for mouse up/down, that the mouse_click event could be changed to fire on mouse up, instead of mouse down.


Thank you for reading :)/>

— TheOriginalBIT
GravityScore #2
Posted 18 February 2013 - 11:10 PM
I think the first suggestion would be useful. It would be useful if you were supporting both normal and advanced computers, you could just os.pullEvent("mouse_click", "key"), instead of using a while statement.
theoriginalbit #3
Posted 18 February 2013 - 11:14 PM
I think the first suggestion would be useful. It would be useful if you were supporting both normal and advanced computers, you could just os.pullEvent("mouse_click", "key"), instead of using a while statement.
One of my thoughts exactly. OR another example with my loading bar api and your monitor resize suggestion…
os.pullEventRaw( "load_bar_"..self.id, "monitor_resize" )
Cloudy #4
Posted 19 February 2013 - 12:07 AM
You're incorrect. Due to the usage of parallel, the parallel code checks using an if statement what events are coming in from Java. You can (and should) just use an if statement.
theoriginalbit #5
Posted 19 February 2013 - 12:11 AM
You're incorrect. Due to the usage of parallel, the parallel code checks using an if statement what events are coming in from Java. You can (and should) just use an if statement.
What do you mean 'usage of parallel'?
Cloudy #6
Posted 19 February 2013 - 12:16 AM
We use parallel in the bios - which means events get sent to Lua regardless.
theoriginalbit #7
Posted 19 February 2013 - 12:22 AM
We use parallel in the bios - which means events get sent to Lua regardless.
Ahh ok. so really using os.pullEvent("timer") has no real advantage over doing

while true do
  local event = os.pullEvent()
  if event == "timer" then break end
end

its just shorter, its not like it uses any less resources or such.
Sebra #8
Posted 19 February 2013 - 03:00 AM
It has advantage of not running routine until event equal to stored filter or "terminate".
It is really a limitation of parallel api. But with single filter this api is more effective. If you wait for several events, you definitely need to distinguish them yourself anyway.

If mouse_click event would be triggered at the moment of button release, whole dragging system would be broken.
theoriginalbit #9
Posted 19 February 2013 - 03:15 AM
If mouse_click event would be triggered at the moment of button release, whole dragging system would be broken.
I don't see why… from the basics I have done with LWJGL

if ( Mouse.getDX() != 0 &amp;&amp; Mouse.getDY() != 0 )
{
  // queue mouse_drag here
}

if (  Mouse.getEventButton() != -1 &amp;&amp; !Mouse.getEventButtonState()  )
{
  // queue mouse_click event here
}
Cloudy #10
Posted 19 February 2013 - 06:52 AM
I'm not going to break existing scripts and cause confusing drag behaviour.
KaoS #11
Posted 24 February 2013 - 08:56 AM
yeah I think it's better to have a click event before a drag so we can see exactly where the drag started, not the next pixel. mouse_up/mouse_down would be great but for now the system works well. the first suggestion can also be coded


local pE=os.pullEvent
os.pullEvent=function(...)
  while true do
	local evts={os.pullEvent()}
	for k,v in pairs({...}) do
	  if evts[1]==v then
		return unpack(evts)
	  end
	end
  end
end
remiX #12
Posted 24 February 2013 - 12:14 PM
yeah I think it's better to have a click event before a drag so we can see exactly where the drag started, not the next pixel. mouse_up/mouse_down would be great but for now the system works well. the first suggestion can also be coded


local pE=os.pullEvent
os.pullEvent=function(...)
  while true do
	local evts={os.pullEvent()}
	for k,v in pairs({...}) do
	  if evts[1]==v then
		return unpack(evts)
	  end
	end
  end
end

local evts={os.pullEvent()}

I think you meant
local evts={pE()}
theoriginalbit #13
Posted 24 February 2013 - 04:12 PM
the first suggestion can also be coded
I said that I knew it could be done! Everyone needs to start READING my posts, this is the 3rd time in suggestions that people have told me that its possible WHEN i have said I know its possible AND supplied a basic example that I know its possible.
Lyqyd #14
Posted 24 February 2013 - 05:47 PM
Locked due to failure to play nicely with others.