$100 to create Mouse Library (getting desperate!)

[stevel05]

Right.. Here's the problem. I have two tablets, one running on API 14 (Android 4.01) and one running on API 15 (Android 4.03). On API 15 all works as you'd like it to. On API 14 the Right mouse button returns the Back Key (Keycode 4) and the Middle mouse button (or scroll wheel click) returns the menu key Keycode 82). Neither create a motion event as the do on API 15.

The new version (attached) handles these for the different API's within the B4A app, but you'll need to define an alternative method to call menu's and exit the app.

It now requires the Reflection library to determine the API level.

 

[stevel05]

I've just seen your additional question, Both can capture the scroll wheel whilst Left or right buttons are pressed API 14 will capture the scroll wheel, API 15 sends another BUTTON_TERTIARY pressed event.

As for the keyboard, I looked at capturing that a year or so ago. External keyboards are OK, the soft keyboards do not deliver key events, and as such are not presented in the keydown or keyup routines.

The library returns a metastate, from which you can determine if any or which particular Shift,Alt or Ctrl keys are pressed on an external keyboard, when the mouse buttons are clicked. Again this works on API 15, I cant test this on my API 14 tablet as I cant attach a mouse and keyboard at the same time.

 

[almontgreen]

API reports as being 17 on my Tronsmart T428 device running Android 4.2.2. Middle mouse button still has no event (nothing happens). Also, RIGHT mouse button aborts program immediately. Everything else is as expected. Maybe the added feature of API 17 is to ignore the middle mouse button? ;^)

 

[stevel05]

Hmm, looks like it's not a simple as the API level then, it must be a manufacturer/hardware thing. Try removing the API check in Activity_Keypress and Activity_KeyUp. It should work then, except that it will capture the back and menu keys too. You'll have to provide alternative menus and exit strategies. Menus for devices with Android 3+ should be via action bar anyway as devices are no longer required to provide a menu key.

To make it work on all devices, it'll need to determine if the mouse buttons return an event or not. Perhaps create a calibration method to see which is sent when the user presses the right button.

 

[almontgreen]

Hmm, looks like it's not a simple as the API level then, it must be a manufacturer/hardware thing. Try removing the API check in Activity_Keypress and Activity_KeyUp. It should work then, except that it will capture the back and menu keys too. You'll have to provide alternative menus and exit strategies. Menus for devices with Android 3+ should be via action bar anyway as devices are no longer required to provide a menu key.

To make it work on all devices, it'll need to determine if the mouse buttons return an event or not. Perhaps create a calibration method to see which is sent when the user presses the right button.

Right mouse button works as expected. Still nothing on the middle mouse button - I suspect it is the firmware somehow as the firmware has a provision for a game controller and I bet that has something to do with it- although I deleted the System_UI.apk which is probably not the best thing to do. However, getting rid of the control bar on the bottom would require a lot more programming knowledge than I have and who knows what the firmware developers did in the customization of the tool bar to handle the game controller interface.

My best guess is that one of the game controller events is identical to the middle mouse button and it gets trapped within the system and never passed to an application... But who knows? The firmware is beta so that's not reassuring.

 

[stevel05]

Here's a calibration option.

Try putting a log(keycode) at the beginning of the Activity_KeyPress to see if the middle mouse button returns anything.

now we see why developers like working on IOS, oooh wash my mouth out!. Did I really say that?

 

[almontgreen]

Here's a calibration option.

Try putting a log(keycode) at the beginning of the Activity_KeyPress to see if the middle mouse button returns anything.

now we see why developers like working on IOS, oooh wash my mouth out!. Did I really say that?

Nothing happening on middle mouse button - like it isn't even being pressed.

 

[stevel05]

Ok, seems unlikely, but how about a log(Action) at the beginning of SW_Action?

 

[almontgreen]

Nope, nothing happening at beginning of SW_Action when pressing middle button. Doesn't look good for this firmware...

 

[almontgreen]

BTW, Stevel05 I did send you a donation via Paypal in appreciation for messing about with this. Hope you got it...

 

[stevel05]

I've just checked and yes I did get it, thanks very much. No email from paypal yet though otherwise I'd have said something sooner.

 

[stevel05]

There is one last possibility, you said you were using a Bluetooth mouse? It may be possible to capture the communication and use that with the Bluetooth Admin in B4A. I don't have a device to try it on, but I'll get hold of one and see.

 

[almontgreen]

No, not using Bluetooth mouse, and prefer to not use it.
BUT I have something else that is interesting. I've been testing the app with the mouse library from "obscure" and noticed that after a few traps and sub executions triggered with the left mouse button that the application suddenly exits. I don't think there are any issues with his library, I think that the system firmware is doing something with the mouse left mouse button events that isn't being nice with my application. And also the middle button! Since it doesn't seem to be passing that event to my application.

Kind of smell a smoking gun here after much hair pulling and banging head. ;^)

I'm thinking that I might simply forget about using the left mouse button and the middle button for now and see what happens with the next firmware release. (or using another device)

 

[stevel05]

There was an issue with the library where null was returned, I allowed for that in my code, but I'm not sure that Obscure's library returned anything (at least in the early version I saw) which may be the problem there.

Another device? It seems that the device cannot be chosen simply on which OS level it is running. My Asus running 4.03 works fine where as your Tronsmart T428 device running Android 4.2.2 doesn't. It seems to be to do with the hardware in the device. perhaps we could ask our B4A user base what their experiences are with the library to decide what hardware to recommend. I would think that the google Nexus would be a safe bet (to be confirmed), i.e. blue chip as in nobody got fired for buying IBM hardware.

 

[almontgreen]

There was an issue with the library where null was returned, I allowed for that in my code, but I'm not sure that Obscure's library returned anything (at least in the early version I saw) which may be the problem there.

Another device? It seems that the device cannot be chosen simply on which OS level it is running. My Asus running 4.03 works fine where as your Tronsmart T428 device running Android 4.2.2 doesn't. It seems to be to do with the hardware in the device. perhaps we could ask our B4A user base what their experiences are with the library to decide what hardware to recommend. I would think that the google Nexus would be a safe bet (to be confirmed), i.e. blue chip as in nobody got fired for buying IBM hardware.

My guess is that the problem has less to do with hardware and more to do with firmware. The T428 firmware (beta!) has customization for interfacing with a game controller. I suspect the smoking gun might lie somewhere in that fact. The "TV dongle" or miniPC products are a moving target - however, the price for these devices is revolutionary and therefore worthwhile to figure out a solution. I doubt if it will be very long before there is one that supports 4k video resolution with much more RAM and faster i/o to ROM and more robust external storage options. The writing is on the wall not only for phones but for smart TVs. Will it be long before toasters have multi-core computers? I doubt it. As to input event trapping, work on libraries like yours are essential tools and worth the effort to create them if only to aid understanding.

So, yes it would be very useful to learn about compatibility with different devices and firmware combinations. I like many aspects of the Tronsmart T428 in terms of performance and cooler operating temperatures but the downside has things like this mouse issue. I will test a QC802 and Zealz GK802 and report my findings. I bet they work fine.