EditTime Message Handling

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?

You mean you want an edittime plugin to set up a Win32 window message pump?

Yeah, that's what I need. I suppose I should have been more specific about that.

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:

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?

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:

  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  )

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.

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.

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.

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.