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

PullEvent, if Char elseif Key, still having issues

Started by augustas656, 04 June 2014 - 05:54 PM
augustas656 #1
Posted 04 June 2014 - 07:54 PM
I do os.pullEvent with no parameter in the brackets, how could I check if the event is a char do this action, and if it's a key do another action. With char being first priority because chars are also keys, and not all keys are chars. I just tried a simple if event == "char" then elseif event == "key" then end, these didn't work, how could I do this?

Regards,
Augustas
Whitecatblack #2
Posted 04 June 2014 - 08:13 PM
augustas656 said:
-snip-
With a small amount of testing, it seems that os.pullEvent() without any parameters, when a key is pressed, will default to event type "key" not "char". So if you want to pull a "char" event instead, you would have to give it that parameter and find a workaround to use it in your code.

[Edit] And disregard what Abelatox said, that isn't how pullEvent works.

Whitecatblack
Edited on 04 June 2014 - 06:14 PM
augustas656 #3
Posted 04 June 2014 - 08:15 PM
Abelatox it won't, event is a string value, key is a table and char is also a table, rather than a string that's set as important variables. I'll get an error string expected, got table.

augustas656 said:
-snip-
With a small amount of testing, it seems that os.pullEvent() without any parameters, when a key is pressed, will default to event type "key" not "char". So if you want to pull a "char" event instead, you would have to give it that parameter and find a workaround to use it in your code.

[Edit] And disregard what Abelatox said, that isn't how pullEvent works.

Whitecatblack

If I recall correctly, bios.lua file's read() function uses this same concept and somehow still manages to work around by using if "char" and if "key" checks. Wierd

Regards
Augustas
Edited on 04 June 2014 - 06:15 PM
Bubba #4
Posted 04 June 2014 - 08:17 PM
augustas656 said:
-snip-
With a small amount of testing, it seems that os.pullEvent() without any parameters, when a key is pressed, will default to event type "key" not "char". So if you want to pull a "char" event instead, you would have to give it that parameter and find a workaround to use it in your code.

Whitecatblack

Nope. os.pullEvent("char") simply waits until it gets the char event. What actually happens is that pressing a key triggers two events: the key event and the char event. If you were to use os.pullEvent() without arguments you would only get the first event which it receives - that would be the key event in most cases. In order to capture all events you'll want to set up a simple loop:

while true do
  local eventType, arg1, arg2, arg3 = os.pullEvent()
  if eventType == "char" then
	...
  elseif eventType == "key" then
	...
  end
end
Edited on 04 June 2014 - 06:29 PM
Whitecatblack #5
Posted 04 June 2014 - 08:49 PM
Bubba said:
What actually happens is that pressing a key triggers two events: the key event and the char event.
Wow, didn't know that. Although it seems it will always pull the key event first, then the char event, if it is a char event. So you would have to do something about that.

Whitecatblack
KingofGamesYami #6
Posted 04 June 2014 - 09:39 PM
Why not just use keys.getName()?

event = {os.pullEvent()}
if event[1] == "key" and keys.getName( event[2] ) then
 --#aha, a character
elseif event[1] == "key" and not keys.getName( event[2] ) then
--#guess its a key event
end
Edited on 04 June 2014 - 07:41 PM
MKlegoman357 #7
Posted 04 June 2014 - 09:46 PM
Why not just use keys.getName()?

event = {os.pullEvent()}
if event[1] == "key" and keys.getName( event[2] ) then
 --#aha, a character
elseif event[1] == "key" and not keys.getName( event[2] ) then
--#guess its a key event
end

Because using 'key' events you cannot tell if the character pressed was capitalized or not.

EDIT: Also, it's shorter:


event = {os.pullEvent()}
if event[1] == "char" then
 --#aha, a character
elseif event[1] == "key" then
--#guess its a key event
end

EDIT2: And keys.getName returns names for not printable keys too, or in other words, for all keys, so in your example the first 'if' would never fail.
Edited on 04 June 2014 - 07:49 PM
KingofGamesYami #8
Posted 04 June 2014 - 09:51 PM
Why not just use keys.getName()?

event = {os.pullEvent()}
if event[1] == "key" and keys.getName( event[2] ) then
 --#aha, a character
elseif event[1] == "key" and not keys.getName( event[2] ) then
--#guess its a key event
end

Because using 'key' events you cannot tell if the character pressed was capitalized or not.

EDIT: Also, it's shorter:


event = {os.pullEvent()}
if event[1] == "char" then
 --#aha, a character
elseif event[1] == "key" then
--#guess its a key event
end

EDIT2: And keys.getName returns names for not printable keys too, or in other words, for all keys, so in your example the first 'if' would never fail.

If you read the OP, he already tried that.. Thanks for mentioning that bit about the key to char conversion, I didn't know that.
theoriginalbit #9
Posted 05 June 2014 - 02:37 AM
Although it seems it will always pull the key event first, then the char event, if it is a char event. So you would have to do something about that.
yes it would, but generally people only deal with specific keys in the key event handling, example

local input = ""
while true do
  local event = { os.pullEvent() }
  if event[1] == "char" then
    input = input..event[2]
  elseif event[1] == "key" then
    if event[2] == keys.enter then
      break
    elseif event[2] == keys.backspace then
      input = input:sub(1, #input - 1)
    end
  end
end
which given what the above statements do it doesn't even matter what order your have the if … elseif in.

Why not just use keys.getName()?
as MKlegoman357 stated doing that will not tell you if the key is capital or not. and the other problem is that getName returns "one", "two", "space", "backslash" instead of "1", "2", " ", "\" so it returns the name of the key, not the printable character.

EDIT2: And keys.getName returns names for not printable keys too, or in other words, for all keys, so in your example the first 'if' would never fail.
not completely true, there are a lot of nil values in the table of names so not all the keys would skip the first if statement.
Keys Table

local tKeys = {
nil,   "one",  "two",  "three",  "four", -- 1
"five",  "six",  "seven",  "eight",  "nine", -- 6
"zero",  "minus",  "equals",  "backspace","tab", -- 11
"q",  "w",  "e",  "r", "t", -- 16
"y", "u", "i", "o", "p", -- 21
"leftBracket","rightBracket","enter","leftCtrl","a", -- 26
"s", "d", "f", "g", "h", -- 31
"j", "k", "l", "semiColon","apostrophe", -- 36
"grave", "leftShift","backslash","z", "x", -- 41
"c", "v", "b", "n", "m", -- 46
"comma", "period", "slash", "rightShift","multiply", -- 51
"leftAlt", "space", "capsLock", "f1", "f2", -- 56
"f3", "f4", "f5", "f6", "f7", -- 61
"f8", "f9", "f10", "numLock", "scollLock", -- 66 
"numPad7", "numPad8", "numPad9", "numPadSubtract","numPad4", -- 71
"numPad5", "numPad6", "numPadAdd","numPad1", "numPad2", -- 76
"numPad3", "numPad0", "numPadDecimal",nil, nil, -- 81
nil,   "f11", "f12", nil, nil, -- 86
nil, nil, nil, nil, nil, -- 91
nil, nil, nil, nil, "f13", -- 96
"f14", "f15", nil, nil, nil, -- 101
nil, nil, nil, nil, nil, -- 106
nil, "kana", nil, nil, nil, -- 111
nil, nil, nil, nil, nil, -- 116 
"convert", nil, "noconvert",nil, "yen", -- 121
nil, nil, nil, nil, nil, -- 126
nil, nil, nil, nil, nil, -- 131
nil, nil, nil, nil, nil, -- 136
"numPadEquals",nil, nil, "cimcumflex","at", -- 141
"colon", "underscore","kanji", "stop", "ax", -- 146
nil, "numPadEnter","rightCtrl",nil, nil, -- 151
nil, nil, nil, nil, nil, -- 156
nil, nil, nil, nil, nil, -- 161
nil, nil, nil, nil, nil, -- 166
nil, nil, nil, nil, nil, -- 171
nil, nil, nil, "numPadComma",nil, -- 176
"numPadDivide",nil, nil, "rightAlt", nil, -- 181
nil, nil, nil, nil, nil, -- 186
nil, nil, nil, nil, nil, -- 191
nil, "pause", nil, "home", "up", -- 196
"pageUp", nil, "left", nil, "right", -- 201
nil, "end", "down", "pageDown", "insert", -- 206
"delete" -- 211
}