Since the Qt library QClipboard is not supported at BB10 there is no Signal emitted as soon as the content of the clipboard is changed. This is a essential feature I need so I need to search for a working solution, even if it is not so optimal.

As far as I'm able to judge I'm forced to use a polling procedure to watch (at example every 500ms) if the content has changed in the meantime. But I have a lot of issues.

This code works fine and the load is very low. So it is not toooo power consuming so I could live with.

BUT, it works only if my app is in the foreground!

I don't understand why. If I start my code, switch to a different app, change the content of the clipboard 3 times and switch back to my app the routine is only able to recognize the last change to the clipboard.

Even while debugging using a breakpoint, the polling routine gets called while a different app is in the foreground but the clipboard doesn't contain any changes so my code doesn't work until the other app goes to the background.

I'm not sure if the clipboard lib is somehow broken or the much-heralded QNX multitasking is somehow limited or perhaps broken.

I'd also carefully consider whether the poll-every-5s approach will be acceptable, since that seems like it might lead to more battery or CPU consumption than would be deemed acceptable. It might prevent the app from being certified as Built For BlackBerry. I'm not sure what your alternatives would be yet, however, so I'm not proposing a solution, just a problem.

I'd also carefully consider whether the poll-every-5s approach will be acceptable, since that seems like it might lead to more battery or CPU consumption than would be deemed acceptable. It might prevent the app from being certified as Built For BlackBerry. I'm not sure what your alternatives would be yet, however, so I'm not proposing a solution, just a problem.

Thank you for the link and you concerns.

Exactly because of this I'm searching for a good solution. The not available QClipboard Library would provide a very good solution using the established "SIGNAL" - "SLOT" concept.

If QClipboard is not supported I wonder if there is alternative solution. I need some kind of interrupt which calls a function in my app as soon as the clipboard gets modified.

QClipboard is actually supported on BB10, but only if you are developing a Qt application that uses either QWidgets or QtQuick. The reason is that QClipboard uses the QPA plugin that is not instanciated in a Cascades app.

But even when using QClipboard you won't get a changed signal when the clipboard content is changed by another application (only your own), because the platform API does not support this (yet).

I think it is ok for your application to poll the clipboard content every 5 seconds, because this operation should not be very CPU intensive.

QClipboard is actually supported on BB10, but only if you are developing a Qt application that uses either QWidgets or QtQuick. The reason is that QClipboard uses the QPA plugin that is not instanciated in a Cascades app.

But even when using QClipboard you won't get a changed signal when the clipboard content is changed by another application (only your own), because the platform API does not support this (yet).

I think it is ok for your application to poll the clipboard content every 5 seconds, because this operation should not be very CPU intensive.

Yes, since Qt and Cascades are the main platform SDK if you do Native C++ development all needed Qt libraries should be supported to get a seamless platform integration. If I do my stuff in pure qml and QtQuick to get QClipboard I won't get the BB10 look and feel. And even there, as you states, doesn't work QClipboard very well.

The problem (since Qt is supported) is that many different ways beside the common Qt Libraries are available to access the clipboard. At MeeGo-Harmattan and core MeeGo was a simple solution for this. Every developer had to use QClipboard to acess the Clipboard. All other Linux ways to do the job were outlawed.

This way the core Qt system was always informed resource-efficient if the Clipboard was changed because there was no way past QClipboard.

In my opinion RIM should have removed the inferior native C++ Libraries early in the beginning and replaced those with a simple wrapper to QClipboard.

Every 5 seconds sounds reasonable at the first place since sometimes are only 2 changes a day made to the clipboard, even once a hour could be fine. But what if a user copies behind one another 2 or 3 items to the clipboard?

There could exists the risk to miss a record. I tested the code myself with 1000ms and I were able to miss a item, with 500ms I were fine... but it feels really, really ugly. If there would be a QSignal if the Clipboard is changed my app could sleep forever until it gets woken up by the system.

borceg wrote:This clipboard include file located here C:\bbndk-10.0.9\target_10_0_9_386\qnx6\usr\include\clipboard should be used or not ? And what's the difference between this and QClipboard ?

The difference between <bb/system/Clipboard> and QClipboard is very fundamental binary stuff without much smart code behind vs. the seamless integration in Qt and Cascades with platform independent encoding translation via QSting and the resource-efficient Signal Slot concept.

The bb/system/Clipboard is currently unable to provide a QSignal or could tell me if the content was 8Bit ASCII or Unicode. A very simple and basic implementation even if at BB10 should exists only a single encoding type. If you transfer or receive later the content to a Windows machine, to Linux or Mac it could get very important which encoding type was used. Same goes to language support with divergent encoding (arabic, chinese). Currently QClipboard is not available at Cascades and not very well implemented (only as a wrapper).

Reading again thru the documentation of <bb/system/Clipboard> there appeared totally new passages during the past days. The old Clipboard code seems the inherit now from QObject. So there was a update at Beta3?

Still no dataChanged Signal, but perhaps a small glimpse of hope to get this finally fixed in the Beta4.