I’m using QNX 6.3.0 SP2. I have created a fairly simple Photon app using PhAB that contains a combobox with hard-coded values (i.e. values were set in PhAB and are not changed by software). When I ‘click’ on my combobox using a touchscreen, the combobox arrow switches directions as though it knows I’ve selected it, but no drop-down selection box appears.
However, if I use Phindows to connect to the application, then the drop-down box appears and everything works well. Also, while Phindows is running, the combobox works perfectly well if I select it from the touchscreen. Once I close Phindows clicking the touchscreen once again fails to produce a drop-down box.
So, my question really is why does the behaviour of the combobox change depending on whether or not I’m connected with Phindows when I am using a touchscreen. Why does Phindows affect the behaviour of the application at all?
I think the difference might have to do with what event is produced when you touch the touch screen. In Phindows, the events that are passed back to QNX are created from a Windows driver and they may be different, or translated differently. To test this, I would create a combobox, and attach all relevent callbacks to it, and see what happens in each environment. You might want to creating events with both a mouse and the touch screen.
Alright, I attached callbacks to all the events except the ‘Raw Events’ and ‘Unfiltered Child Events’. In both cases (running Phindows or not) I received the same sequence of events:
Pt_CB_REALIZED
Pt_CB_ACTIVATE
Pt_CB_GOT_FOCUS
Pt_CB_SELECTION
Pt_CB_CBOX_CLOSE
Note that in this scenario I was not actually selecting an item, just getting the list to open and closing it.
I thought that since I was getting the Activate and Got_Focus that I could just call PtComboBoxListOpen() to force the list to open, but that didn’t seem to have any effect. My best guess at this moment is that the list is somehow opening in the background but with Phindows connected it properly opens in the foreground???
Anything else that I could check? I unfortunately cannot attach a mouse to my system with the touchscreen.
Was there no Pt_CB_ENABLE/DISABLE callback?
Is there such a thing as Pt_CB_ENABLE or DISABLE? I can’t find it documented. I did not receive the Pt_CB_ARM/DISARM callback.
Sorry, yes I meant ARM/DISARM. That’s a little curious. It might be right, but I’d have thought you would get both those callbacks. I think it might be important to find out if you get them when using a mouse. I’ll check this and get back to you.
I just found another interesting behaviour. I’ve been starting Phindows remotely so I can actually use application on the touchscreen. Normally, I resize the Phindows window so I can see the entire screen. However, I got lazy and failed to resize it so that in Phindows I could only see half the combobox. When I used the touchscreen, I could only see half the drop-down list. Let me state this again so I make sure it’s clear because it’s confusing to me.
Although the entire screen looks normal on the touchscreen and I can see the label and arrow of the combobox, I can only see the portion of the drop-down list that is visible in the remote Phindows screen.
So, it appears that it is not simply the Phindows/phrelay connection that is actually magically making my app work as I had first thought.
Note that the application uses the combobox to determine the content of a PtMultiText object. Whether or not Phindows is running, the multi-text object is correct.
Any ideas??
First let me report that I’ve determined that ARM/DISARM do not ever seem to be called when interacting with a mouse.
Your description suggests an obvious question. Does this problem where the pull down list does not appear on the main screen only occur when you are simultaneously using Phindows, or does it also happen when Phindows is not running? If it is the former, I would suggest that Phindows is somehow interfering with the correct rendering of the box.
Phindows must of course catch draw events at they come out from the screen, and if were incorrectly opaque to the draw events that draw the pull down list, then this would explain this behavior. Phindows sees the draw events, and forwards them to the remote system, but the local display driver never gets them.
On the other hand, if you see this problem alone, without Phindows, then it sounds more like some kind of touch screen driver bug.
The only other possibility I can think of is, that you are doing something strange in your callbacks that cause this weird behavior. If you think this is possible, I’d create a simple application with just a combo box, and some printf’s in all the callbacks and see if you still get the problem.
The problem happens even if Phindows is not running. We noticed that the app works with Phindows by accident as we were using Phindows for testing. I should be able to test the app today using a different type of touch screen to see if it is a driver problem. I’ll also try creating a basic app with a combobox to see if it is simply the app itself. I only have one callback on the close (Pt_CB_CBOX_CLOSE) so I would be suprised if the problem was in the callback, but it certainly could be something in the application.
Well, here is some practical advise for getting this dealt with. Build a very small program that demonstrates this, just a window and a combo box if possible. You might want to post it here just in case someone else can find your problem. Test it with both touch screens, and a mouse if possible. If you post it, I will be glad to verify that it works right with a mouse. Then pass it on to QSSL tech support. If you make it that easy for them, you should get better response.
Excellent suggestion. I built a very simple combobox app with no callbacks, no real code at all (except for the generated abmain.c file). I tested it on an elo and microtouch touchscreen and it works on the microtouch, but not the elo. It exhibited the exact same behaviour as the full app (i.e. if phindows is started, whatever is visible in Phindows works on the touchscreen) So, as you suggested, it could be that there is something funny going on with devi-elo or maybe the video card (both elo and microtouch screens were using the same s3savage driver)? Or possibly something wrong with how I’m starting devi-elo (started with: devi-elo smartset -R uart -1)?
Anyway, I’ve attached my fantastic sample combobox app. Let me know if you have any other suggestions. I know QNX support is off training until March 1st, I’m hoping to have a solution by then, but if it’s a driver problem I guess I’ll just submit my problem and wait.
The test program works just as one would expect using a mouse.