EditTime Message Handling

Forum for plugin, effect and behavior programmers. Please use the Help & Support forum for help using Construct.

Post » Wed Dec 30, 2009 5:21 am

Is it possible using the current SDK to setup a proper event handler for the edittime side of plugin development? I know the physics plugin has a basic one, but since you can only get the message, you can't detect, for example, which keyboard key is being pressed or anything.

Anything I can do here?
Moderator
B
98
S
37
G
19
Posts: 1,584
Reputation: 17,817

Post » Wed Dec 30, 2009 3:38 pm

You mean you want an edittime plugin to set up a Win32 window message pump?
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Wed Dec 30, 2009 4:42 pm

Yeah, that's what I need. I suppose I should have been more specific about that.
Moderator
B
98
S
37
G
19
Posts: 1,584
Reputation: 17,817

Post » Thu Dec 31, 2009 8:43 pm

Well, I've been messing around with the way the physics behavior handles Windows messages for the custom collision mask editor.

I've achieved some success by checking for "WM_KEYDOWN" messages, then using the GetKeyState() function to see if the key I'm looking for is down, which works fine, but no "WM_KEYUP" messages seem to come through the pipe. Here's the code:

[code:1apw4ljp]void EditExt::OnMessage(int message)
{
switch (message)
{
case WM_KEYDOWN:
{
if (GetKeyState(VK_SHIFT) < 0)
{
shiftDown = true;
}
break;
}
case WM_KEYUP:
{
if (GetKeyState(VK_SHIFT) >= 0)
{
shiftDown = false;
}
break;
}

}

}

void WINAPI ETOnMessage(editInfo* editObject, int message)
{
editObject->objectPtr->OnMessage(message);

}[/code:1apw4ljp]
No matter what I do with the keyboard, I never receive any WM_KEYUP messages. I've double checked for this by having the program throw itself into an infinite loop upon receiving a WM_KEYUP message, but it never does.

I can't imagine this is intentional on Construct's part, but I could be wrong. Is there some way around this, or am I just doing something wrong?
Moderator
B
98
S
37
G
19
Posts: 1,584
Reputation: 17,817

Post » Thu Dec 31, 2009 9:42 pm

I think there's alot of issues with WM_KEYUP that gets affected by alot of other things
but look at MouseKeyboard on key released:
[code:a6fhixbn]
214 long ExtObject::cKeyReleased(LPVAL params)
215 {
216 int key = params[0].GetInt();
217
218 bool& first = keyReleaseFirst[keyTable[key].vk];
219 bool ret = MakeConditionTrigger(pRuntime, !KeyIsDown(keyTable[key].vk)) && !first;
220 first = false;
221 return ret;
222 }[/code:a6fhixbn]


it believe they bypassed WM_KEYUP, and are using a variable to keep track of whether this is the first time the specific key was not down

which is how I did it for custom controls as well (since I basically copy/pasted from this :D )
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Fri Jan 01, 2010 1:05 am

I haven't encountered any problems at runtime involving WM_KEYUP messages. In fact, it worked just fine when I tested it. It just seems to be the edittime, which poses problems since it works fundamentally differently from the runtime.

For now, I've found a way around this for my particular setup, but it's less than ideal.
Moderator
B
98
S
37
G
19
Posts: 1,584
Reputation: 17,817

Post » Sat Jan 02, 2010 12:54 am

Davo, any ideas on this? I think Davo added that for receiving keyboard input for the custom collision mask editor, but maybe Construct doesn't forward all kinds of window message.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Tue Jan 26, 2010 11:05 pm

Well, I really need this working, so I guess I'll resurrect this with some new things I've found.

First off, lifting the message handling code from the physics behavior and placing it in a fresh copy of a newer version of the SDK doesn't work. The only way I got my own message handling plugin was by clearing out the physics behavior code of everything physics related and using it as a base.

I've noticed David seems to have done the same thing for the bone movement behavior, as it's based on an ancient SDK as well. Unfortunately, when I attempted this I seem to have broken something related to actions, expression, and conditions because they don't work anymore. :P

Another thing that's closely related. With the current SDK, trying to capture the frame editor crashes Construct when your plugin is a behavior. It doesn't crash when it's a standalone plugin, so I don't know what's up with that. :?
Moderator
B
98
S
37
G
19
Posts: 1,584
Reputation: 17,817


Return to Construct engineering

Who is online

Users browsing this forum: No registered users and 0 guests