Functionality with SetWindowsHookEx WH_JOURNALPLAYBACK

raja_s_patil · Post by **raja_s_patil** » Mon Oct 17, 2011 1:11 am

Hello,

I am trying to run our own Delphi Application with wine 1.2 on Kubuntu.

Applications runs without any problems but Functionality of stuffing keys with
setWindowsHookEx(WH_JOURNALPLAYBACK, @Playback, hInstance, 0); is not working at all.

Can somebody suggest any work around for this ? If any code changes are
needed we can do the same since we have sources of application with us.
Since application is Data Entry Centric this functionality is Vital to Client and
can stop them from switching to Linux to use this application. Rest of the
matters like printing, fonts etc. etc. have been settled very nicely with wine.

Thanks and Warm regards

Raja

Paul Romanyszyn · Post by **Paul Romanyszyn** » Mon Oct 17, 2011 9:10 am

On 10/17/2011 02:11 AM, raja_s_patil wrote:

Hello,

I am trying to run our own Delphi Application with wine 1.2 on Kubuntu.

Applications runs without any problems but Functionality of stuffing keys with
setWindowsHookEx(WH_JOURNALPLAYBACK, @Playback, hInstance, 0); is not working at all.

Can somebody suggest any work around for this ? If any code changes are
needed we can do the same since we have sources of application with us.
Since application is Data Entry Centric this functionality is Vital to Client and
can stop them from switching to Linux to use this application. Rest of the
matters like printing, fonts etc. etc. have been settled very nicely with wine.

Thanks and Warm regards

Raja

Try with a newer wine as 1.2 is very old. Also it may be possible to
port the app to linux using
http://wiki.lazarus.freepascal.org/Laza ... lphi_Users
Paul R.

raja_s_patil · Post by **raja_s_patil** » Mon Oct 17, 2011 10:30 am

Thanks Paul Romanyszyn,

Paul Romanyszyn wrote: Try with a newer wine as 1.2 is very old.

We tried with Latest Wine From WineHQ repositories but application had
lot problems in startup it self as well we were not able to run it properly.
so we reverted back to Kubuntu repository wine which we found to be
working in all respect except this functionality.

Paul Romanyszyn wrote: Also it may be possible to port the app to linux using
http://wiki.lazarus.freepascal.org/Laza ... lphi_Users
Paul R.

Yes its an option but it will invite lot of work since we have not tries Lazarus. We know that it will be beneficial in long run but at this moment
time is constraint and project dead line is very short. Well your suggestion
is well taken and we will take up ride with Lazarus as soon as this project
is over and port the application to it so that it will run natively on Linux.

Anyways If there is any other suggestion its welcome.

Thanks and warm regards

Raja

Post by **DanKegel** » Tue Oct 18, 2011 2:16 pm

It's hard to help when you're on an old version of wine.

Can you find the most recent version of wine that lets your
app start up properly? Knowing which change to wine broke
your app will help us find a fix.
(See also http://wiki.winehq.org/RegressionTesting )

Another long-shot idea:
try running reactos in virtualbox and seeing if it runs your app.

raja_s_patil · Post by **raja_s_patil** » Wed Oct 19, 2011 11:28 am

DanKegel wrote:It's hard to help when you're on an old version of wine.

Can you find the most recent version of wine that lets your
app start up properly? Knowing which change to wine broke
your app will help us find a fix.
(See also http://wiki.winehq.org/RegressionTesting )

Another long-shot idea:
try running reactos in virtualbox and seeing if it runs your app.

Well I use Kubuntu 10.04 LTS and update it weekly. Wine 1.2.2Obuntu2 is the latest wine available in repositories. I tried to use latest one from Wine repositories but it gives lots of problems even for few windows application already running with Kubuntu wine. so I reverted back to Default repositories.

The application runs with VMware since I develop in Delphi VM and test there itself. I dont use any windows machine for development. This functionality is working Fine there without any problems.

I guess since setWindowsHookEx is using system wide hook and there is no real Windows running in wine it might not be able to function as expected, experts are welcome to comment on this guess.

Thanks and warm regards.

Raja

lahmbi5678 · Post by **lahmbi5678** » Wed Oct 19, 2011 5:48 pm

It seems a bit strange, that newer wine versions are that unstable for you. Maybe you should install a recent wine version, move or rename your .wine folder and create a new .wine folder by running winecfg (that will automatically create a new .wine folder). Then install your application again in the new .wine folder.

If it still doesn't work, you can delete the newer .wine folder and move the old .wine folder back.

In that case you should file a bug, and provide a link to a free trial version of your app, if possible. The best thing would be a demo app with all unneeded functionality removed, just enough code to demonstrate the bug.

Unfortunately it might take some time, until this bug is fixed. If you need it running right now, you might be better off with a VM like virtualbox, VMWare.

raja_s_patil · Post by **raja_s_patil** » Wed Oct 19, 2011 8:19 pm

lahmbi5678 wrote:It seems a bit strange, that newer wine versions are that unstable for you. Maybe you should install a recent wine version, move or rename your .wine folder and create a new .wine folder by running winecfg (that will automatically create a new .wine folder). Then install your application again in the new .wine folder.

If it still doesn't work, you can delete the newer .wine folder and move the old .wine folder back.

In that case you should file a bug, and provide a link to a free trial version of your app, if possible. The best thing would be a demo app with all unneeded functionality removed, just enough code to demonstrate the bug.

Unfortunately it might take some time, until this bug is fixed. If you need it running right now, you might be better off with a VM like virtualbox, VMWare.

Thanks lahmbi5678,

I will try once again with new version Installed directly from Wine repositories with changes you have suggested and test. I will also create a small application specifically using the functionality I need and Post it here along with sources so that experts can apply their minds to full extent. I will try to do it today itself. Resolution of issue can be extended by couple of weeks say by this month end or 1st week of Nov due to other functional changes in application are in progress as per new requirements from client. Client is also discussing with employees and judging "what if this functionality is missing" for switch over to Linux at Lan Nodes.

By today evening or latest by tomorrow I will post the updates on this issue along with problems after switching to new version.

Thanks and warm regards.

Raja

lahmbi5678 · Post by **lahmbi5678** » Wed Oct 19, 2011 9:55 pm

It might be useful to post the terminal output when running our app with wine (run it from console, if you don't do already). There should be some error messages from wine, especially if it doesn't run at all.

Can you explain in simple words, why you need SetWindowsHookEx?
I assume, you want the user to be able to control your application by pressing certain keys, even if the application doesn't have focus (could your app keep the focus?).

One possible workaround for linux might be to extend your app with a socket, that accepts commands (in form of text messages like "play"). Additionally you'd need an xlib application running in the background, that captures keyboard events, like in [1] or [2]. After the user pressed a key for play, the xlib application would have to connect to the port of your app, sending the command "play", then your app could do the necessary stuff. This approach comes without warranty, I'm not sure, if it would work perfectly. And it would be some work, but probably the best you can do, if you need it running in a few weeks on linux (without Windows VMs).

[1] http://stackoverflow.com/questions/4037 ... h-x11-xlib
[2] http://kaizer.se/wiki/keybinder/

raja_s_patil · Post by **raja_s_patil** » Wed Oct 19, 2011 10:22 pm

lahmbi5678 wrote:It might be useful to post the terminal output when running our app with wine (run it from console, if you don't do already). There should be some error messages from wine, especially if it doesn't run at all.

I did fresh install from wine repositories and followed your suggestions. It worked and application is running Fine with Latest Wine. But the Key stuffing is still not working. I am creating a small application with the problematic functionality only for posting here. While posting exe and sources of that I will post console output too.

lahmbi5678 wrote: Can you explain in simple words, why you need SetWindowsHookEx?
I assume, you want the user to be able to control your application by pressing certain keys, even if the application doesn't have focus (could your app keep the focus?).

As explained earlier the application under consideration is a data entry centric application where many times some repeated phrases are need to be keyed in. Since work is to be finished in limited time frame data entry operators requested us to built key stuffing functionality in application when a particular shortcut key is pressed like say <ctrl><shift> B will paste "Bank Of India, Kolhapur Branch" in edit which has keyboard focus. In some cases it automates work like shift to other application copy to clipboard current selection, again shift back and paste. But this usage is very limited and users are ready to sacrifice it while shifting to wine, but not the key stuffing as explained above.

lahmbi5678 wrote: One possible workaround for linux might be to extend your app with a socket, that accepts commands (in form of text messages like "play"). Additionally you'd need an xlib application running in the background, that captures keyboard events, like in [1] or [2]. After the user pressed a key for play, the xlib application would have to connect to the port of your app, sending the command "play", then your app could do the necessary stuff. This approach comes without warranty, I'm not sure, if it would work perfectly. And it would be some work, but probably the best you can do, if you need it running in a few weeks on linux (without Windows VMs).

[1] http://stackoverflow.com/questions/4037 ... h-x11-xlib
[2] http://kaizer.se/wiki/keybinder/

Well we have thought of another alternative is generating Keyboard messages for keys to stuff since inter application functionality can be dropped. We plan see how SetWindowsHookEx can be resolved for couple of days then think of alternatives. Thanks for suggesting an option we will definitely explore it along with other options since many of our applications use this functionality since its part of our common application framework which we use for development of applications and its one of our USPs, so we are very serious on this functionality.

Thanks and warm regards

Raja

lahmbi5678 · Post by **lahmbi5678** » Thu Oct 20, 2011 3:07 am

If your app actually has focus, the socket option is way too bloated. I shouldn't have brought it up.

Your best bet is to file a bug and provide as much information as possible, including a demo/trial app.

vitamin · Post by **vitamin** » Thu Oct 20, 2011 8:58 am

raja_s_patil wrote:setWindowsHookEx(WH_JOURNALPLAYBACK, @Playback, hInstance, 0);

WH_JOURNALPLAYBACK is only partially implemented. From my own experience, anything related to hooks "partially implemented" means broken.

lahmbi5678 · Post by **lahmbi5678** » Thu Oct 20, 2011 1:04 pm

An alternative approach, if your app always has focus, might be to track WM_SYSKEYDOWN events, these are triggered, when you press keys like <Ctrl>, <Shift>, etc. Once such an event was triggered, you'd have to check if the <B> key is pressed (at the same time) too, to track something like <Ctrl-Shift-B>.

Again, this proposal comes without warranty.

lahmbi5678 · Post by **lahmbi5678** » Thu Oct 20, 2011 1:11 pm

Posted a bit too quick, even with that alternative approach, you'd have to emulate the WH_JOURNAL_PLAYBACK functionality. Depending on how complex your "macros" (sequences of keyboard events) are, it might be the sanest approach to wait for wine to implement it properly.

raja_s_patil · Post by **raja_s_patil** » Thu Oct 20, 2011 1:19 pm

lahmbi5678 wrote:An alternative approach, if your app always has focus, might be to track WM_SYSKEYDOWN events, these are triggered, when you press keys like <Ctrl>, <Shift>, etc. Once such an event was triggered, you'd have to check if the <B> key is pressed (at the same time) too, to track something like <Ctrl-Shift-B>.

Again, this proposal comes without warranty.

Yes lahmbi5678, posting series of SYSKEYDOWN and SYSKEYUP events is an alternate option we have thought of if "SetWindowsHookEx WH_JOURNALPLAYBACK" is not working as expected in wine. But in this there is flaw that if Focus is changed from application then its not possible to restore it back since all messages will be posted w.r.t. a Application handle.
Exactly this was done when we developed a Test application to have key stuffing functionality and later it was changed to use SetWindowsHookEx WH_JOURNALPLAYBACK after seeing the drawback. Unfortunately we dont have source for that since it was discarded long back when SetWindowsHookEx WH_JOURNALPLAYBACK started functioning satisfactorily But we remember a broad outline of work to do. so we have spend couple of days to get back to that point of a lame keystuffing functionality but happy that at least 90-95% requirement will be fulfilled.

Hoping that SetWindowsHookEx WH_JOURNALPLAYBACK works fine with wine.

Thanks and warm regards

Raja