I am trying to read SMS messages from Symbian phone inbox. I created an app with Qt Creator and got it working in Symbian Simulator, but in Nokia N8 it cannot read any messages (SMS or email).
Here is my minimal code:
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QtCore/QCoreApplication>
#include <QMessageManager>
QTM_USE_NAMESPACE
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent), ui(new Ui::MainWindow)
{
ui->setupUi(this);
QMessageManager mm;
QMessageIdList msgs = mm.queryMessages();
ui->textBrowser->append(QString("Messages %1").arg(msgs.size()));
for (int i = 0; i < msgs.count(); ++i) {
QMessage message = mm.message(msgs.at(i));
ui->textBrowser->append(message.from().addressee());
ui->textBrowser->append(message.to().at(0).addressee());
ui->textBrowser->append(message.textContent());
}
}
// ...rest is boilerplate code
In simulator this prints the test messages it has. In N8 it displays only "Messages 0" although there are SMS and email messages.
In .pro file I have declared
CONFIG += mobility
MOBILITY += messaging
I am new to Qt so this may well be something everyone takes for granted. I tried debug and release builds, and also copying the sis file Qt Creator created to the phone and installing it, but the result is the same.
Check out User guide: Symbian Signed. For reading SMS messages, you need to add ReadUserData capability for symbian. In .pro file, add
symbian:TARGET.CAPABILITY += ReadUserData
Related
My WPF app consumes a third-party Win32 dll that logs messages via OutputDebugString.
I can see the OutputDebugString messages in Visual Studio or via DebugView, but I don't want to ask my customer to run DebugView. I'd like to capture the messages from OutputDebugString and automatically log them to a file, so if the customer has a problem, I can just ask her to send me that log file.
Is this possible? Or does the user necessarily have to start DebugView, reproduce the error, and then send me the log that way?
Hook OutputDebugStringW. I'd suggest using the Detours library for this.
#include <windows.h>
#include <detours.h>
#pragma comment(lib, "detours.lib")
BOOL SetHook(__in BOOL bState, __inout PVOID* ppPointer, __in PVOID pDetour)
{
if (DetourTransactionBegin() == NO_ERROR)
if (DetourUpdateThread(GetCurrentThread()) == NO_ERROR)
if ((bState ? DetourAttach : DetourDetach)(ppPointer, pDetour) == NO_ERROR)
if (DetourTransactionCommit() == NO_ERROR)
return TRUE;
return FALSE;
{
#define InstallHook(x, y) SetHook(TRUE, x, y)
VOID (WINAPI * _OutputDebugStringW)(__in_z_opt LPCWSTR lpcszString) = OutputDebugStringW;
VOID WINAPI OutputDebugStringHook(__in_z_opt LPCWSTR lpcszString)
{
// do something with the string, like write to file
_OutputDebugStringW(lpcszString);
}
// somewhere in your code
InstallHook((PVOID*)&_OutputDebugStringW, OutputDebugStringHook);
#Cody Gray's suggestion to "write your own debug listener, and then you've basically written an inferior clone of DebugView" sounds like it might actually be an answer to my question.
Here's a C# implementation of a basic OutputDebugString capture tool. I'd seen it in my Googling a couple of times, but my eyes glazed over it, assuming, "that can't possibly be what I want, can it?" Turns out, it just might be the answer to my question.
After getting DBUS working on OS X Mavericks after a lot of problems, I have one last problem.
My Apps are not able to interact with the Buses, if i am not in the directory, where libdbus is.
For just making it clear:
The simple program following, that is basically the Widgets-Template, is used for testing:
#include "mainwindow.h"
#include "ui_mainwindow.h"
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
QDBusConnection con = QDBusConnection::sessionBus();
std::cout << "Connection status " << con.isConnected() << std::endl;
}
MainWindow::~MainWindow()
{
delete ui;
}
When running this out of QT Creator, i will get:
Connection status 0
When moving to my lib-Path (it is /opt/local/lib/; installed dbus via ports), and call /path/to/project/executable, i am getting:
Connection status 1
So what I have to do to be able to start my app from every location?
I'm looking for a way to determine if the Mac running my game has more than one mouse attached. The typical real world example is a MacBook (with built in trackpad) with an external mouse connected.
My game has different control set ups for common configurations like keyboard+mouse, just keyboard (e.g., a MacBook with just the trackpad, no mouse) and gamepad. Ideally I'll be able to detect this in the game and set the controls accordingly.
I'm planning to support Mac OS 10.7+.
Is there a Cocoa (or non-Cocoa) API I can use to get this information?
For reference, I've ask (and got an answer) for a similar question for Windows-based computers.
you should deal with IOKit... the following sample enumerates all the USB devices connected to the system, you can use that to see if there's a pointing device attached:
#include <IOKit/IOKitLib.h>
#include <IOKit/usb/IOUSBLib.h>
int main(int argc, const char *argv[])
{
CFMutableDictionaryRef matchingDict;
io_iterator_t iter;
kern_return_t kr;
io_service device;
/* set up a matching dictionary for the class */
matchingDict = IOServiceMatching(kIOUSBDeviceClassName);
if (matchingDict == NULL)
{
return -1; // fail
}
/* Now we have a dictionary, get an iterator.*/
kr = IOServiceGetMatchingServices(kIOMasterPortDefault, matchingDict, &iter);
if (kr != KERN_SUCCESS)
{
return -1;
}
/* iterate */
while ((device = IOIteratorNext(iter)))
{
/* do something with device, eg. check properties */
/* ... */
/* And free the reference taken before continuing to the next item */
IOObjectRelease(device);
}
/* Done, release the iterator */
IOObjectRelase(iter);
return 0;
}
The internal trackpad should be seen as an attached USB device but I'm not sure about that...
I ended up using ManyMouse, a cross-platform library for detecting the number of mice attached to a computer. On OSX it uses HIDManager to detect mice. Once it's built getting the number of mice attached to the system is a one-liner:
const int available_mice = ManyMouse_Init();
I wanna to compile my c plus plus project that using boost library with WDK rather than VisualStudio.
My computer's OS is Windows7-64bit, the WDK version is 7.6 and boost library version is 1.51
Once I compile my source code project, the WDK compiler will occure an error:
e:\lib\boost_1_51_0\boost\array.hpp(72) : error C2039: 'ptrdiff_t' : is not a member of 'std' .
Whole project's file contents are as follow:
File sources:
TARGETTYPE=PROGRAM
TARGETNAME=helloworld
UMENTRY=main
USE_MSVCRT=1
USE_NATIVE_EH=1
#
# use iostream package and STL
#
USE_IOSTREAM=1
USE_STL=1
STL_VER=70
#
# my boost library root directory
#
BOOST_INC_PATH=E:\lib\boost_1_51_0
INCLUDES=$(BOOST_INC_PATH)
TARGETLIBS=$(SDK_LIB_PATH)\user32.lib
SOURCES=HelloWorld.cpp
UMTYPE=console
UMBASE=0x4000000
File HelloWorld.cpp:
#include <iostream>
#include <vector>
#include <string>
#include <boost/array.hpp>
void InvokeVector()
{
//invoke STL's vector
std::vector<std::string> vec;
vec.push_back("Entry ");
vec.push_back("of ");
vec.push_back("Vector");
vec.push_back("……\n");
//print vec
for (int i=0; i<vec.size(); i++) {
std::cout<<vec.at(i);
}
}
void InvokeBoost()
{
//invoke Boost's array<T, N>
boost::array<int, 3> arr = {1, 2, 3};
for (int i=0; i<arr.size(); i++) {
std::cout<<"arr["<<i<<"]"<<"is" <<arr[i]<<std::endl;
}
}
int main()
{
// InvokeVector(); //run normally
InvokeBoost(); //it will occure an error
return 0;
}
Could you please teach me how to solve this problem? Any help will be greatly appreciated!
Short answer: No.
But you can port some.
It's well explained here : The NT Insider:Guest Article: C++ in an NT Driver
One of the main problems with C++ in the
kernel is that most of the "nice" features of the language are not
directly available in that mode. Some are easy to recreate and we will
see how to do that. However, some features should be forgotten such as
C++ exceptions, which are not the same as kernel exceptions.
Such features have to be forgotten simply because there is no support
for them in kernel mode. Translation: does not compile. If you have
the time and energy you may attempt to port them to kernel mode, but
frankly, exceptions are too slow for kernel mode. This will have an
impact on your C++ coding style, which is something you should keep in
mind.
longer answer - yes
just add
typedef int ptrdiff_t;
before pulling in boost headers and all will be well for basic boostness
I have a mixed C++/Objective-C project that uses AudioObjectGetPropertyDataSize to get the number of audio devices (such as USB headsets) plugged in. This API doesn't seem to work under certain conditions. For example, on 10.5 it will work but on 10.6 it won't detect when a new USB headset is plugged in.
I've pared down the problem to a small bit of code that reproduces the problem (it calls AudioObjectGetPropertyDataSize in a loop). The code will work on 10.6 (ie, it will detect when devices are plugged/unplugged) when its only linked against CoreAudio, but once you link against Foundation it will stop working.
I don't understand how linking to a framework can break code that otherwise works.
Here is the code (coreaudio-test.cpp):
#include <stdio.h>
#include <CoreAudio/AudioHardware.h>
int main(int argc, char **argv) {
printf("Press <enter> to refresh device list> \n");
while (1) {
getchar();
// get device count
UInt32 dataSize = 0;
AudioObjectPropertyAddress propertyAddress;
propertyAddress.mSelector = kAudioHardwarePropertyDevices;
propertyAddress.mScope = kAudioObjectPropertyScopeGlobal;
propertyAddress.mElement = kAudioObjectPropertyElementMaster;
OSStatus result =
AudioObjectGetPropertyDataSize(kAudioObjectSystemObject, &propertyAddress, 0, NULL, &dataSize);
int count = -1;
if (result == noErr) {
count = dataSize / sizeof(AudioDeviceID);
}
printf("num devices= %d \n", count);
}
return 0;
}
And here is the Makefile:
LFLAGS= -framework CoreAudio
all: coreaudio-test coreaudio-test.broken
# create a test that works
coreaudio-test: coreaudio-test.cpp
g++ -o $# $^ $(LFLAGS)
# linking to foundation will break the test
coreaudio-test.broken: coreaudio-test.cpp
g++ -o $# $^ $(LFLAGS) -framework Foundation
Any thoughts on this bizarre behavior? (btw, I've also posted this question on the CoreAudio list.)
The CoreAudio List answered my question. We need to tell CoreAudio to allocate its own event-dispatching thread:
CFRunLoopRef theRunLoop = NULL;
AudioObjectPropertyAddress theAddress = { kAudioHardwarePropertyRunLoop, kAudioObjectPropertyScopeGlobal, kAudioObjectPropertyElementMaster };
AudioObjectSetPropertyData(kAudioObjectSystemObject, &theAddress, 0, NULL, sizeof(CFRunLoopRef), &theRunLoop);
I suspect what's happening is that when the program is linked to Foundation, CoreAudio assumes the main thread is acting as an event dispatcher loop (very common since Objective-C is usually used for GUI programs). When not linking against Foundation, I guess it figures that it needs to allocate its own event thread.
Related behavior, which is like 9 years ago someone reported:
http://lists.apple.com/archives/coreaudio-api/2001/May/msg00021.html