Prepare3d KeyupKeydown

[crushpilot]

Hi

 

Configuration:

 

Win7 FSUIPC (version 4.96) prepar3D V1,V2,V3

 

For my program development I use VB.6 included FSUIPC SDK.

I need KeyUP and KeyDown to simulate keystrokes.

In FSX no Problems.

In prepar3D the values FSUIPC and FS never reach.

 

The simple test:

 

In the FSUIPC module, I choose "Key Presses" then "Set".

 

So, now I send via my program for example a "K".

 

Under FSX the sent "K" appears in the input field like a keyboard input.

 

Under prepar3D nothing appears.

Where does the button hang?

 

Greeting

[Pete Dowson]

Please ALWAYS post support questions to the Support Forum, not to places like the FAQ subforum, which is a reference place for others to find things.

I've moved this one for you.

6 hours ago, crushpilot said:

In the FSUIPC module, I choose "Key Presses" then "Set".

So, now I send via my program for example a "K".

Under FSX the sent "K" appears in the input field like a keyboard input.

Sorry, there is almost no useful information here. You are programming a Key press to do something in FSUIPC's Key assignment tab? To do what, exactly?

What is this "input field" you speak of, where you expect a "K" to appear? Why would a "K" appear anywhere in any case if you have assigned it to do something?

You really do need to be much more explicit. i.e

-- What is "K" assigned to do? An FS or FSUIPC control? Which?  Or something else?
-- How is your program actually sending it? Via a Windows facility, via some FSUIPC controls? What?
-- What is supposed to happen when the "K" is used?

I also need ALWAYS to know things like version of FSUIPC (the number, exactly), and the version of P3D.

Have you tried using FSUIPC's logging facilities to examine your problem?

Pete

 

[crushpilot]

The problem is not the allocation of a key.

The FSUIPC window (key presses) I use only to test whether the keystroke is recognized.

The real problem is: why the key sendet by the VB.6 program (keybd_event) does not find the way into the FSUIPC (only in prepare3D !).

 

FSUIPC version       4.962

Prepare3D                3.4.22.19868

Simconnect               3.4.0.0

VB.6                           8176

 

I had no problems of this kind with all MS Simis.

 

In the Appendix: VB.6 Program Extraction

 

Greatings

H.P.

VB Program Extraction

' ***************************  Keys ********************************

Public Sub KeyDown(ByVal vKey As KeyCodeConstants)
   keybd_event vKey, 0, 0, 0
End Sub

Public Sub KeyUp(ByVal vKey As KeyCodeConstants)
   keybd_event vKey, 0, 2, 0
End Sub
 

keybd_event

The keybd_event function synthesizes a keystroke. The system can use such a synthesized keystroke to generate a WM_KEYUP or WM_KEYDOWN message. The keyboard driver's interrupt handler calls the keybd_event function.

Windows NT: This function has been superseded. Use SendInput instead.

VOID (
  BYTE bVk,           // virtual-key code
  BYTE bScan,         // hardware scan code
  DWORD dwFlags,      // flags specifying various function options
  DWORD dwExtraInfo   // additional data associated with keystroke
);
 

[Pete Dowson]

19 hours ago, crushpilot said:

The FSUIPC window (key presses) I use only to test whether the keystroke is recognized.

The real problem is: why the key sendet by the VB.6 program (keybd_event) does not find the way into the FSUIPC (only in prepare3D !).

Sorry, you are trying to use Windows Messages to interface to P3D, not FSUIPC?

Rather than use FSUIPC assignments to "see" if a key is arriving, why not simply use the Key/Button logging in FSUIPC's logging tab, and enable the Console log? Then if you run P3D in windowed mode you can see what Keyboard events FSUIPC detects.

Did you not see this, BTW?

19 hours ago, crushpilot said:

This function has been superseded. Use SendInput

Pete

 

[crushpilot]

5 hours ago, Pete Dowson said:

Sorry, you are trying to use Windows Messages to interface to P3D, not FSUIPC?

Sorry too! I try nothing !The key transfer in this way has been running for 18 years in 35 FSX Simis without problems. Only with prepare3D does not work.

There must be a difference between FSX and prepare3D.

5 hours ago, Pete Dowson said:

Did you not see this, BTW?

This affects Windows NT.

H.P.

 

[Pete Dowson]

4 minutes ago, crushpilot said:

Sorry too! I try nothing !The key transfer in this way has been running for 18 years in 35 FSX Simis without problems. Only with prepare3D does not work.

Of course FSX and P3D are different!

But you misunderstand. I still do not understand how you are sending keystrokes. Doing what?  If you are not using FSUIPC for this, then why are you here? If you are not sending krystrokes, what is and what is your question about?

6 minutes ago, crushpilot said:

This affects Windows NT.

You misunderstand Windows documentation. Superseded in NT means SINCE NT -- i.e. in all versions of Windows since then! NT was just when it was changed. All versions of Windows since then were based on NT code, not on the older Windows 16 bit versions!

Pete

 

[crushpilot]

I think it is the best when I explain the problem more precisely.

Basically, the keystroke function is only a nice accessory.

We develop and manufacture motion platforms (2DOF, 3DOF) and corresponding controllers and softwares. 

Your ingenious development of the FSUIPC has brought great relief.. Thanks !

The controllers for the servo motors (HIM, Siemens etc.) communicate mainly via Ethernet, RS485 or RS232 
with protocols TPC / IP or ProfiBUS.

In the FS computer (along with  FSUIPC) is running our interface module called "cockBIT" (a VB6 program included Visual Basic <-> FSUIPC / 
WideFS Communication version 1.005 FSUIPC SDK) . This allows keyup keydown functions via FSUIPC.

CockBIT reads all data required for the motion via FSUIPC and calculates the motion characteristic. 
This is communicated via profiBUS (Siemens) to the servo controller (bank, pitch etc.). 
That  all works perfectly. 

To have a better order in the (moving) cockpit we  installed a small alfa-numeric keyboard in the B737 "outfit" . 
Via the same communication (same as Motion) the keyboard sends its identification (I am the special keyboard and on me the key 5 was pressed). 
CockBIT converts this information into a KeyUP or KeyDOWN function. 
This is used to make airfield names or other small entries in the FS windows.
Or the Motion Controller has the possibility to trigger keyboard-based functions.
That's all.

But the question remains. Why does not it work under prepar3D? 
Has something changed in the fsuipc_sdk with regard to prepare3D? 
The version is still 1,005!

The science does not ask "why", but only "how". 
But I'm interested in  to know "why".
 

Greatings

H.P.

[Pete Dowson]

14 minutes ago, crushpilot said:

This allows keyup keydown functions via FSUIPC.

Right.. And the best way to do that is to use the FSUIPC controls specially added for that very purpose -- one of these:

1070 Key Press and Release (param is Keycode + 256*Shift code, or JsBk)
1071 Key Press/Hold (param is Keycode + 256*Shift code, or JsBk)
1072 Key Release  (param is Keycode + 256*Shift code, or JsBk

(as listed on page 33 of the Advanced User's Guide).

You can send any control, FS or FSUIPC-added, via offset 3110.

20 minutes ago, crushpilot said:

CockBIT converts this information into a KeyUP or KeyDOWN function.

But why, if you are using FSUIPC? You said earlier you were using  keybd_event which is nothing to do with FSUIPC, but is an obsolete Windows API function, not used by FSUIPC for many years!

If you are bypassing FSUIPC and trying to use Windows functions directly with P3D and they do not work, your recourse is Windows or P3D support, not FSUIPC support.

24 minutes ago, crushpilot said:

But the question remains. Why does not it work under prepar3D? 
Has something changed in the fsuipc_sdk with regard to prepare3D?

There are lots of Offset updates since the SDK was published. Each new FSUIPC Install includes an up to date Offsets list, installed into your FSUIPC Documents folder -- that's your prime reference for the use of Offsets -- and interim changes are always listed in the "Changes" documents included with the Installer. The SDK contents just form the base.

However, none of this seems relevant to your implementation because you seem to have explained that you are not using FSUIPC for this.

Pete

 

[crushpilot]

29 minutes ago, Pete Dowson said:

But why, if you are using FSUIPC? You said earlier you were using  keybd_event which is nothing to do with FSUIPC, but is an obsolete Windows API function, not used by FSUIPC for many years!

Aha .. now it is slowly logical.

30 minutes ago, Pete Dowson said:

Right.. And the best way to do that is to use the FSUIPC controls specially added for that very purpose -- one of these:

1070 Key Press and Release (param is Keycode + 256*Shift code, or JsBk)
1071 Key Press/Hold (param is Keycode + 256*Shift code, or JsBk)
1072 Key Release  (param is Keycode + 256*Shift code, or JsBk

Yes exactly. This way is the best. The direct Windows functions regarding keyboard via my VB6 program are obviously suppressed in the P3D.

I think the problem is solved in the approach.

Many Thanks

H.P.

[crushpilot]

Hi

I have not yet reached countable results regarding key transfer.
But what would lead me quickly to the goal would be a concrete example:

How would the 8-byte (3110) record look with the following function:

Key Press and Release (1070) shift + K

I thank you for the effort.

Greeting
H.P.

[Pete Dowson]

4 hours ago, crushpilot said:

How would the 8-byte (3110) record look with the following function:

Key Press and Release (1070) shift + K

The "8-byte record" is, of course, two 32-bit (byte) values, the parameter in 3114 and the command (1070) in 3110. It is the writing of the command which triggers the action, so either write both as one 8-byte structure, or write the parameter first, then the command (in one Process call).

The keycode is the standard Windows keycode, all of which are listed in the Advanced Users guide (which is also where the 1070 description above comes from). -- see page 22, where you will see that K has keycode 75. On the following page you find the shift codes, where you see Shift is 1 -- but normally you'd also add the 8 (for "normal"), though I don't think this is strictly necessary.

So the end result for the parameter has 9 in the 2nd byte (256 x 9) and 75 in the 1st, or low byte. i.e. in the 32-bits:

0x0000094B = 2379 decimal.

Please do use the documentation provided. It is all in your FSUIPC Documents subfolder.

Pete

 

[crushpilot]

......tadaaaaaa 

Works perfectly in FSX and P3D ...

Many Thanks

H.P.