Set focus to VIEW00

[Tom-D]

I come here today on bended kneeboard, helmet in hand, hoping I haven't overlooked something obvious.

My goal is to assign a button on my CH yoke to change the window focus to the parent window (VIEW 00) and set the view to Virtual Cockpit Forward. The latter is easy, the former is where I am having trouble. In my research, searching this forum, other sim forms, P3D documentation, FSX documentation and, of course, FSUIPC documentation. I have not found a way to programaticly bring focus to VIEW00, the parent window of P3D.

According to P3D's documentation there are only three ways to get to VIEW00: mouse click in the window, choose VIEW00 from the View menu, and key "s" to cycle through the views. None of these is appropriate for a button operation.

If anyone has any ideas on how to accomplish this, please let me know.

Thanks

[Pete Dowson]

1 hour ago, Tom-D said:

My goal is to assign a button on my CH yoke to change the window focus to the parent window (VIEW 00) and set the view to Virtual Cockpit Forward. The latter is easy, the former is where I am having trouble. In my research, searching this forum, other sim forms, P3D documentation, FSX documentation and, of course, FSUIPC documentation. I have not found a way to programaticly bring focus to VIEW00, the parent window of P3D.

According to P3D's documentation there are only three ways to get to VIEW00: mouse click in the window, choose VIEW00 from the View menu, and key "s" to cycle through the views. None of these is appropriate for a button operation.

I don't know what all of the P3D/FSX controls do -- are such actions assignable at all in FSX/P3D assignments at all? If not then probably there is no way other than mouse. I think I've always used the "S" method (or rather its generated control) to cycle through standard views, but I don't know if that works with created views. Possible these controls may help (found in the List of controls in your FSUIPC Documents folder.

VIEW_AUX_00
VIEW_AUX_01
VIEW_AUX_02
VIEW_AUX_03
VIEW_AUX_04
VIEW_AUX_05

Pete

 

[Tom-D]

Pete, Thanks for the prompt response.

I had looked at those controls but when issuing VIEW_AUX_00, focus does not move to VIEW00. By their names one might think that they might be helpful in making a view get focus but alas, that did not appear to be the case.

There is an old post on the P3D forum http://www.prepar3d.com/forum/viewtopic.php?t=110755 which makes reference to the lack of view management. In all of my searching, this is the only forum post that found with a query along the lines of mine. I would think that this is such an obvious thing to want to do (forcing focus to the parent window) there would be many discussions about it.

I guess it's not the big deal I thought it might be.

 

TD

 

[Pete Dowson]

8 hours ago, Tom-D said:

I would think that this is such an obvious thing to want to do (forcing focus to the parent window) there would be many discussions about it.

You might be ble to do it using a Lua plug-in, using the mouse facilities there.

But, no, whilst there are controls to view different panels, and of course cameras, there seems to be nothing for selecting specific views when you have more than one open.

Pete

 

[Tom-D]

Some time ago I remember reading a statement in the FSUIPC Advanced User's Guide that might have been the answer to my issue.

In the Buttons Programming section:

KeyboardFocus: When this is included and set to 'Yes' it ensures that any keypresses assigned to buttons (or sent by
external programs as FSUIPC controls) are directed to the main FS window for processing.

I've entered KeyboardFocus=Yes in the Buttons section of the ini file but it seems not to have the effect that I want. In fact it appears to have no effect at all. Is this still a valid option? I see it in the oldest Advanced User's Guide I have (early 4.x) and also in the most recent. The option seems easy enough to employ. Is there something I might be missing in its use or am I misinterpreting what the option actually does?

[Pete Dowson]

24 minutes ago, Tom-D said:

KeyboardFocus: When this is included and set to 'Yes' it ensures that any keypresses assigned to buttons (or sent by
external programs as FSUIPC controls) are directed to the main FS window for processing.

I've entered KeyboardFocus=Yes in the Buttons section of the ini file but it seems not to have the effect that I want. In fact it appears to have no effect at all. Is this still a valid option? I see it in the oldest Advanced User's Guide I have (early 4.x) and also in the most recent. The option seems easy enough to employ. Is there something I might be missing in its use or am I misinterpreting what the option actually does?

Possibly.  Are your other views docked or undocked?

Multiple windowed views are all part of the FS process. It's a long time ago when that option was implemented, but I think that what it does is switch focus back to FS itself when it currently is on another process altogether.  The keyboard focus actually needed for FS to receive the keypresses is the FS window procedure within FS, of class "FS98MAIN", which processes all Windows messages. It is to that "main window" which the keyboard focus is changed IF it isn't already there.

So, tell me, are you sending keypresses to FS for it to process which it isn't processing because of focus being elsewhere?

Oh, BTW, that option is much older than "early 4.x", ;-)

Pete

 

[Tom-D]

 

On 10/14/2017 at 7:08 PM, Pete Dowson said:

Possibly.  Are your other views docked or undocked?

I tested KeyboardFocus=yes with both a docked and undocked VIEW_01. With focus in this view, a button command did not send focus to VIEW_00 :-(

 

Multiple windowed views are all part of the FS process. It's a long time ago when that option was implemented, but I think that what it does is switch focus back to FS itself when it currently is on another process altogether.  The keyboard focus actually needed for FS to receive the keypresses is the FS window procedure within FS, of class "FS98MAIN", which processes all Windows messages. It is to that "main window" which the keyboard focus is changed IF it isn't already there.

So, tell me, are you sending keypresses to FS for it to process which it isn't processing because of focus being elsewhere?

My goal is to send the control (Virtual Cockpit Forward) to View00 regardless of what other window might have focus at the time. I thought if KeyboardFocus=yes worked as I had thought then I could send some keystroke prior to sending the control.

 

Oh, BTW, that option is much older than "early 4.x", ;-)

I figured as much but my first experience with FSUIPC was in 2010 when I moved beyond a single joystick and acquired a yoke, throttle quadrant and pedals.

Like you, I've been using FS since the Amiga days (flying around San Francisco bay.) FS  1 and 2 for the PC were the gold standard for ensuring that an IBM clone was fully compatible with its namesake. My small company build our own clones for resale to the publishing industry. We used FS at trade expos to show that we met the "total clone compatibility" standard.  

 

 

Anything is possible in software but some things are easier than others. I would consider suggesting to LM that it create a control code to bring focus to a the given view. Barring that, it could add the underline flag to the VIEWS menu view section (VIEW00 - VIEW09) . Unfortunately, at least on my machine, selecting a menu choice via keystrokes is unreliable  whether using the actual keyboard or sending a key sequence with a button.

Using, as a test, the keyboard sequence ALT, V ,W to toggle Window Titles,  I found that the results were (1) move the selection to WORLD, (2) do nothing or (3) toggle titles.  Using a button to send these three keys is even less successful. FWIW, sending ALT+V (K86,24) does not work at all. This assignment works to toggle WINDOW TITLES about 10 percent of the time:

1=PY,1,K18,8     -{Key press: (null)}-
2=PY,1,K86,8     -{Key press: V}-
3=PY,1,K87,8     -{Key press: W}-

Most likely, if the view numbers were underlined, selecting them via a button could not be done with any consistency.

I may be on a fool's errand here.

The testing was done with P3D 4.1 and FSUIPC 5.121b

 

 

[Pete Dowson]

28 minutes ago, Tom-D said:

selecting a menu choice via keystrokes is unreliable  whether using the actual keyboard or sending a key sequence with a button.

Yes, it isn't recommended I'm afraid. Any use of ALT seems to be rather unreliable

Maybe you can try sending ALT with the "press/hold" control (1071), then the correct letter for the menu, sending the ALT key release (1072) after.

These added FSUIPC controls are documented on page 25 of the Advanced Users guide.

Pete

 

 

[Tom-D]

Just to tie up the loose ends of this thread, I did try using the press/hold control with only limited success.

This sequence:

58=PY,1,C1071,2066     -{key press/hold: (null)}-
59=UY,1,K86,8     -{Key press: V}-
60=UY,1,K87,8     -{Key press: W}-
61=UY,1,C1072,2066     -{key release: (null)}-

 

and this sequence:

58=HY,1,K18,8     -{Key press: (null)}-
59=HY,1,K86,8     -{Key press: V}-
60=PY,1,K87,8     -{Key press: W}-

both result in toggling Window Titles with the latter being more consistent than the former.

With each, the menus must be unhidden. Two button presses are required to achieve the desired result once if the menus are hidden.

Likewise each scenario leaves focus on the menus thus preventing any further action until clicking off the menu area. With actual keystrokes, focus is returned to the window after the menu operation is completed. 

This says to me that even if  VIEW00-VIEW09 (underlining) was implemented by LM, controlling the menu by a button would not be reliable enough to accomplish my desire to direct focus to VIEW00 before sending VIRTUAL COCKPIT FORWARD.

I will ask LM on the P3D forum if they would create a control to select a given view.

Thanks for your suggestions, Pete. Still lovin' FSUIPC!

[Pete Dowson]

16 hours ago, Tom-D said:

58=PY,1,C1071,2066     -{key press/hold: (null)}-
59=UY,1,K86,8     -{Key press: V}-
60=UY,1,K87,8     -{Key press: W}-
61=UY,1,C1072,2066     -{key release: (null)}

Surely you don't want ALT V and ALT W? Shouldn't the release be before the W?

One problem you'll be encountering, which is impossible to get around this way, is that as soon as a menu is opened, the main thread in FSUIPC can no longer get keypresses read by FS -- the focus changes to the menu, and any keypresses still in the main FS buffer are seen after you exit the menu.

You really do need a Lua plug-in which operates separately, in its own thread. More below.

16 hours ago, Tom-D said:

With each, the menus must be unhidden. Two button presses are required to achieve the desired result once if the menus are hidden.

You really need a delay holding the ALT down. You can't really do that with simple keypress assignments, you'd need to use a Lua plug-in.

And for successful use of keypresses from a Lua plug-in for doing quite complex see the example "Payload737.lua" in the Examples ZIP in your FSUIPC documents folder. (At least it used to be 100% successful -- I've never tried int in P3D4).

16 hours ago, Tom-D said:

Likewise each scenario leaves focus on the menus thus preventing any further action until clicking off the menu area. With actual keystrokes, focus is returned to the window after the menu operation is completed. 

Exactly.

16 hours ago, Tom-D said:

This says to me that even if  VIEW00-VIEW09 (underlining) was implemented by LM, controlling the menu by a button would not be reliable enough to accomplish my desire to direct focus to VIEW00 before sending VIRTUAL COCKPIT FORWARD.

Rather than "VIEW00-VIEW09 (underlining)" in menus, surely you want working controls you can send, not menus? 

If you know where the views are positioned you could use a Lua plug-in to move then click the mouse on them to move focus. 

Pete

 

[Tom-D]

 

" surely you want working controls you can send, not menus? "

In a word, ABSOLUTELY!

My only reason for this exercise was to see if it was practical to select a menu choice with a button.

I have no idea what might be involved in creating a control to select a view. I do have some Windows programming experience and know that setting a character to underline in a menu list is very easy.

My thought was to ask LM to create controls to select views or, if that is too difficult, underline the view numbers. Since the latter would not be a practical solution, I will only suggest the former.

Truly, I don't hold out much hope that either would be done.   

[Pete Dowson]

1 hour ago, Tom-D said:

I have no idea what might be involved in creating a control to select a view. I do have some Windows programming experience and know that setting a character to underline in a menu list is very easy.

The underlining is not very useful if you can't sent the character to use it -- which could be done using Lua as shown in the example in the ZIP in the FSUIPC Documents folder "Payload737.lua".

You can't invent new controls to do new things unless there's a way provided to do them in the underlying software (i.e. P3D), so, yes, it would involve L-M adding controls. 

For defined Cameras you can use the "VIEW CAMERA SELECT" 0 - 9 controls, but I think the cameras have to have an ID (0-9) specified, and probably all they do is put that view into your currently selected window.

Pete

 

 

 

[Tom-D]

Having read in other posts that new controls are available in P3D4.1, I'm wondering if any of these deal directly with window selection? (I say window specifically as "view" is used to refer to both the container and the contents of the container in most documentation.)

 

TD

 

[Pete Dowson]

1 hour ago, Tom-D said:

Having read in other posts that new controls are available in P3D4.1, I'm wondering if any of these deal directly with window selection? (I say window specifically as "view" is used to refer to both the container and the contents of the container in most documentation.)

I don't think so, but by all means look for yourself. i attach the list i've extracted from P3D4.1 -- in ID order as well as the order supplied by index. The left most number is just the time entry (the data is from an FSUIPC5.LOG file), so ignore that. the second number is just the index -- the list as supplied is in that order.  Third number is the actual control number FSUIPC5 will be using. 

The name of the control, which will appear in the FSUIPC5 assignments lists is followed by the description provided. That's enclosed in ' characters.

This won't be the published list, of course. I'll tidy it up first. I'm also getting some errors -- 4 new COM STBY RADIO controls are rejected even though supplied in the list by P3D4!

Pete

Event list for P3D4.1.zip