Yup, good idea, but I guess it won't work in a keyboardregisterCursorKey called function, because even if I wait 10 seconds to read the tab control, it gives me the old one back, see the example I've send in the repley message to Doug.
Ralf Kefferpuetz * Germany * MSN/Live: [email protected] * Aim: RalfKatEMC * Skype/Yahoo: rkefferpuetz7747 * -----Original Message----- From: Jeff Bishop [mailto:[email protected]] Sent: Monday, November 15, 2010 8:25 PM To: [email protected] Subject: RE: Keyboard.RegisterCursorKey question Why not do a do loop and look for the change in the tab control's index if it is a standard one after the key press? -----Original Message----- From: Ralf Kefferpuetz [mailto:[email protected]] Sent: Monday, November 15, 2010 12:22 PM To: [email protected] Subject: RE: Keyboard.RegisterCursorKey question Yes, even a sleep 10000 did not work... I assigned a hot key to this function to make sure that I'm not looking to something wrong and when pressing this hotkey just after control enter was pressed it tells me the correct path. In the worst case I could create a subroutine which does nothing else as sending the hotkey to the keyboard when pressing control-tab, but that wouldn't be a satisfactory solution. I will upload an update for the Total Commander script tomorrow on script central, with the registerCursorKey disabled, so you can have a look to it. Many thanks, Ralf Ralf Kefferpuetz * Germany * MSN/Live: [email protected] * Aim: RalfKatEMC * Skype/Yahoo: rkefferpuetz7747 * -----Original Message----- From: Rasmussen, Lloyd [mailto:[email protected]] Sent: Monday, November 15, 2010 7:11 PM To: [email protected] Subject: RE: Keyboard.RegisterCursorKey question Did you include a delay in your script? The new data may not be displayed for a fraction of a second when you change folders. Lloyd Rasmussen, Senior Project Engineer National Library Service for the Blind and Physically Handicapped Library of Congress 202-707-0535 http://www.loc.gov/nls The preceding opinions are my own and do not necessarily reflect those of the Library of Congress, NLS. -----Original Message----- From: Ralf Kefferpuetz [mailto:[email protected]] Sent: Monday, November 15, 2010 12:30 PM To: Rasmussen, Lloyd; [email protected] Subject: RE: Keyboard.RegisterCursorKey question Hello Doug, well, I have an application , a file manager (Total Commander),with tabs in it. Hitting control-tab brings me to the next tab. Each tab changes the list view with files, means the directory path of the list view. I simply want WE to announce the new path, which is related to a tab. I tried the following: dim cKey(2), KeyLabel set cKey(0) = Keyboard.RegisterCursorkey("Control-Tab", "currentPanel", ClientInformation.ApplicationProcess, "Key07") Sub currentPanel(myKeyId) .. code for reading the control which holds the path string... End Sub You see, it now always reads the path of the actual path, not the one which is active after control-tab is released. I hope this explains a bit better what I'm trying to achieve. Cheers and thanks a lot, Ralf Ralf Kefferpuetz * Germany * MSN/Live: [email protected] * Aim: RalfKatEMC * Skype/Yahoo: rkefferpuetz7747 * -----Original Message----- From: Doug Geoffray [mailto:[email protected]] Sent: Monday, November 15, 2010 2:59 PM To: [email protected] Subject: Re: Keyboard.RegisterCursorKey question Ralf, After reading this again I think I was confused on what you were asking. When you do a Keyboard.RegisterCursorKey the even fires after the application sees the key. You stated it fires before which is not correct. It only fires once and that is after the application see it. I was referring to cursoring keys which are part of the set file. If you hook Application.OnCursorKey then what I said is true but that isn't what you are doing or asking. If this isn't what you want or need then maybe explaining exactly what you are wanting to do would help me give you better advice of how to get there. Doug On 11/15/2010 8:30 AM, Doug Geoffray wrote: > Ralf, > > When you register OnCursorKey it actually fires both before the > application sees it and after the application sees it. Meaning you > are guaranteed to get the event twice with each single keypress. The > IsBeforeApplication flag that gets sent to your event handler > indicates if it is firing before or after. > > Isn't this what you are asking for? > > But as an fyi, just because it fires after the application sees the > keypress, it doesn't guarantee the application did anything with it or > at least did anything with it yet. However, normally it works fine. > Typical problems may be if the application is sluggish to > respond...say it is working over a slow network of some sorts for > example. > > Regards, > Doug > > On 11/14/2010 10:17 AM, Ralf Kefferpuetz wrote: >> Hello all, >> >> as far as I understand it right the Keyboard.RegisterCursorKey fireds >> the function, before the cursorKey is passed to the application. Do >> we have something similar to Keyboard.RegisterCursorKey, but it >> should fire up after the key is passed to the application? >> >> Many thanks, >> Ralf >> >> Ralf Kefferpuetz >> * Germany >> * MSN/Live: [email protected] * Aim: RalfKatEMC * Skype/Yahoo: >> rkefferpuetz7747 * >> >>
