I am trying to get touch inputs for my program targeting an N8 (and a C7), and I am not able to create a QList for keeping touchpoints using QTouchEvent::touchPoints(). The program crashes with the following line: Thread has crashed: A data abort exception has occurred accessing 0xee
The overloaded events function looks like:
bool GLWindow::event(QEvent *event)
{
switch ( event->type() ) {
case QEvent::TouchBegin: {
QList<QTouchEvent::TouchPoint> touchBeginPoints =
static_cast<QTouchEvent *>(event)->touchPoints();
foreach (const QTouchEvent::TouchPoint &touchBeginPoint, touchBeginPoints)
{
float touchBeginX = touchBeginPoint.pos().x();
float touchBeginY = touchBeginPoint.pos().y();
qDebug() << "touchBeginPoint := " << touchBeginX << ", " << touchBeginY;
}
break;
}
case QEvent::TouchUpdate: {
// same as touch begin: getting touch point
break;
}
case QEvent::TouchEnd: {
// same as touch begin: getting touch point
break;
}
default: {
qDebug() << "Goodbye";
return true;
}
}
return true;
}
Now,
I have never worked with containers before. But creating and using a QList in another part of the program works fine. Should I be including something in my .pro file? (Most problems seem to end up regarding this with me!)
I read (a bit) about exceptions in Qt and Symbian, but I am not able to get most of that. BUT I am not doing any networking or resource based i/o or manipulation except textures for 3D objects. Is it possible that memory allocation while running the program is creating some problem?
Basically I am just trying to print the touch point. But I am clueless as to why I can’t create a QList. The code compiles fine. I tried my best (unsuccessfully), but is there any other way to get the screen coordinates of a touchpoint (one that does not require a QList)? Any comments are welcome.
[Reposting from qt-project.org.]
Your syntax is 100% correct. Just look at this example: http://www.developer.nokia.com/Community/Wiki/Painting_in_Qt
What I'm guessing happens is that QTouchEvent::touchPoints() returns a list big enough that it overflows your stack. Try increasing the stack size for your application.
Is your syntax correct ? The compilation error seems to reinforce teukkam point...
What happens when you replace
static_cast<QTouchEvent *>(event)->touchPoints()
With
(dynamic_cast<QTouchEvent *>(event))->touchPoints()
Notice the parentheses...
Related
I'm modifying the Qt 5 Terminal example and use a QTextEdit window as a terminal console. I've encountered several problems.
Qt does a strange interpretation of carriage return ('\r') in incoming strings. Ocassionally, efter 3-7 sends, it interprets ('\r') as new line ('\n'), most annoying. When I finally found out I choose to filter out all '\r' from the incoming data.
Is this behaviour due to some setting?
Getting the cursor interaction to work properly is a bit problematic. I want the console to have autoscroll selectable via a checkbox. I also want it to be possible to select text whenever the console is running, without losing the selection when new data is coming.
Here is my current prinout function, that is a slot connected to a signal emitted as soon as any data has arrived:
void MainWindow::printSerialString(QString& toPrint)
{
static int cursPos=0;
//Set the cursorpos to the position from last printout
QTextCursor c = ui->textEdit_console->textCursor();
c.setPosition(cursPos);
ui->textEdit_console->setTextCursor( c );
ui->textEdit_console->insertPlainText(toPrint);
qDebug()<<"Cursor: " << ui->textEdit_console->textCursor().position();
//Save the old cursorposition, so the user doesn't change it
cursPos= ui->textEdit_console->textCursor().position();
toPrint.clear();
}
I had the problem that if the user clicked around in the console, the cursor would change position and the following incoming data would end up in the wrong place. Issues:
If a section is marked by the user, the marking would get lost when new data is coming.
When "forcing" the pointer like this, it gets a rather ugly autoscroll behaviour that isn't possible to disable.
If the cursor is changed by another part of the program between to printouts, I also have to record that somehow.
The append function which sound like a more logical solution, works fine for appending a whole complete string but displays an erratic behaviour when printing just parts of an incoming string, putting characters and new lines everywhere.
I haven't found a single setting regarding this but there should be one? Setting QTextEdit to "readOnly" doesn't disable the cursor interaction.
3.An idea is to have two cursors in the console. One invisible that is used for printouts and that is not possible at all to manipulate for the user, and one visible which enables the user to select text. But how to do that beats me :) Any related example, FAQ or guide are very appreciated.
I've done a QTextEdit based terminal for SWI-Prolog, pqConsole, with some features, like ANSI coloring sequences (subset) decoding, command history management, multiple insertion points, completion, hinting...
It runs a nonblocking user interface while serving a modal REPL (Read/Eval/Print/Loop), the most common interface for interpreted languages, like Prolog is.
The code it's complicated by the threading issues (on user request, it's possible to have multiple consoles, or multiple threads interacting on the main), but the core it's rather simple. I just keep track of the insertion point(s), and allow the cursor moving around, disabling editing when in output area.
pqConsole it's a shared object (I like such kind of code reuse), but for deployment, a stand-alone program swipl-win is more handy.
Here some selected snippets, the status variables used to control output are promptPosition and fixedPosition.
/** display different cursor where editing available
*/
void ConsoleEdit::onCursorPositionChanged() {
QTextCursor c = textCursor();
set_cursor_tip(c);
if (fixedPosition > c.position()) {
viewport()->setCursor(Qt::OpenHandCursor);
set_editable(false);
clickable_message_line(c, true);
} else {
set_editable(true);
viewport()->setCursor(Qt::IBeamCursor);
}
if (pmatched.size()) {
pmatched.format_both(c);
pmatched = ParenMatching::range();
}
ParenMatching pm(c);
if (pm)
(pmatched = pm.positions).format_both(c, pmatched.bold());
}
/** strict control on keyboard events required
*/
void ConsoleEdit::keyPressEvent(QKeyEvent *event) {
using namespace Qt;
...
bool accept = true, ret = false, down = true, editable = (cp >= fixedPosition);
QString cmd;
switch (k) {
case Key_Space:
if (!on_completion && ctrl && editable) {
compinit2(c);
return;
}
accept = editable;
break;
case Key_Tab:
if (ctrl) {
event->ignore(); // otherwise tab control get lost !
return;
}
if (!on_completion && !ctrl && editable) {
compinit(c);
return;
}
break;
case Key_Backtab:
// otherwise tab control get lost !
event->ignore();
return;
case Key_Home:
if (!ctrl && cp > fixedPosition) {
c.setPosition(fixedPosition, (event->modifiers() & SHIFT) ? c.KeepAnchor : c.MoveAnchor);
setTextCursor(c);
return;
}
case Key_End:
case Key_Left:
case Key_Right:
case Key_PageUp:
case Key_PageDown:
break;
}
you can see that most complexity goes in keyboard management...
/** \brief send text to output
*
* Decode ANSI terminal sequences, to output coloured text.
* Colours encoding are (approx) derived from swipl console.
*/
void ConsoleEdit::user_output(QString text) {
#if defined(Q_OS_WIN)
text.replace("\r\n", "\n");
#endif
QTextCursor c = textCursor();
if (status == wait_input)
c.setPosition(promptPosition);
else {
promptPosition = c.position(); // save for later
c.movePosition(QTextCursor::End);
}
auto instext = [&](QString text) {
c.insertText(text, output_text_fmt);
// Jan requested extension: put messages *above* the prompt location
if (status == wait_input) {
int ltext = text.length();
promptPosition += ltext;
fixedPosition += ltext;
ensureCursorVisible();
}
};
// filter and apply (some) ANSI sequence
int pos = text.indexOf('\x1B');
if (pos >= 0) {
int left = 0;
...
instext(text.mid(pos));
}
else
instext(text);
linkto_message_source();
}
I think you should not use a static variable (like that appearing in your code), but rely instead on QTextCursor interface and some status variable, like I do.
Generally, using a QTextEdit for a feature-rich terminal widget seems to be a bad idea. You'll need to properly handle escape sequences such as cursor movements and color mode settings, somehow stick the edit to the top-left corner of current terminal "page", etc. A better solution could be to inherit QScrollArea and implement all the needed painting–selection-scrolling features yourself.
As a temporary workaround for some of your problems I can suggest using ui->textEdit_console->append(toPrint) instead of insertPlainText(toPrint).
To automatically scroll the edit you can move the cursor to the end with QTextEdit::moveCursor() and call QTextEdit::ensureCursorVisible().
In Qt 5.1, I'm having an issue with QXMLStreamReader waiting for a QProcess to produce more data.
If I read lines from an unbuffered QProcess, it works fine:
while(!vupProcess.state() == QProcess::NotRunning)
{
if (vupProcess.atEnd())
{
vupProcess.waitForReadyRead();
}
qDebug() << vupProcess.readLine();
}
It's pretty clear cut: when the buffer is out of data, it waits until there is more. When there is more, it will print lines without waiting.
Now, if I want to do the same with QXMLStreamReader, it works, but the processing of the XML elements happens at the wrong moment (too late).
Consider this:
QXmlStreamReader xml;
xml.setDevice(&vupProcess);
QStack<VUPDevice *> deviceStack;
QXmlStreamReader::TokenType tokenType = QXmlStreamReader::NoToken;
while (tokenType != QXmlStreamReader::EndDocument && !xml.hasError())
{
if (xml.device()->atEnd())
{
xml.device()->waitForReadyRead(XML_READNEXT_TIMEOUT);
}
tokenType = xml.readNext();
if (xml.hasError())
{
qDebug() << "ERROR";
return;
}
...
}
By the time waitForReadyRead(int) is called, a lot of elements are available already, and I need them processed to update the GUI. However, it won't continue until the QProcess starts to output more. It seems to be because the underlying QProcess is read till it's empty as fast as possible, and then my parser unnecessarily hangs in the early stages, because the QProcess doesn't output anymore.
What I need, is xml.hasMoreElements(), so that I can make:
if (xml.device()->atEnd() && !xml.hasMoreElements())
{
xml.device()->waitForReadyRead(XML_READNEXT_TIMEOUT);
}
But I can't seem to find an API call that does this for me.
So, how do I not wait for more data when it's not necessery?
I guess I solved it. There is no method for asking if there ar more XML elements, but the readNext() call will put the QXMLStreamReader object in a state you can detect, and use to have the back-end device wait:
QXmlStreamReader::TokenType tokenType = xml.readNext();
while (xml.error() == QXmlStreamReader::PrematureEndOfDocumentError)
{
xml.device()->waitForReadyRead(XML_READNEXT_TIMEOUT);
tokenType = xml.readNext();
}
if (xml.hasError())
{
...
}
I don't really understand why this is happening at all. I'm trying to open a file to read some data into my program but failbit gets set instantly, having moved error messages around it seems that failbit actually gets set before I even attempt input.open(). The undeclared variables in the code are globals which live elsewhere (messy but will refine later) Here's the offending function from a larger project:
int read_input()
{
ifstream input;
string value;
int file_complete=0;
int count=0;
if(input.failbit)
printf("Really?\n");
input.clear();
input.open("Input.txt");
while(!file_complete)
{
if(input.failbit)
{
printf("Reading in set-up value number %d failed.", count+1);
getchar();
return 1;
}
else if(input.eofbit)
{
file_complete=1;
}
if(input.get()=='=')
{
getline(input, value);
switch(count)
{
case 0:
n_loci=atoi(value.c_str());
count++;
break;
case 1:
n_founders=atoi(value.c_str());
count++;
break;
case 2:
n_self=atoi(value.c_str());
count++;
break;
// Add more cases later
}
}
}
input.close();
return 0;
}
This program for me turns out:
Really?
Reading in set-up value number 1 failed.
I'm assuming I've done something very stupid but have been at this quite a while now.
P.S I'm compiling with the latest version of g++ on cygwin on top of Windows 7.
OK fixed this myself now:
Failbit seems to be set by EOFs in some implementations so instead I switched to using input.good() and consequently all was good.
There was also some logical error in my program with the checking for "=" part too as ifstream.get() returns it's value as an integer so I needed to cast them back into chars for comparison.
I want to use the Irrnet network library in an Irrlicht game.
The source code uses Linux sockets and I'm trying to port it for Windows replacing it with code that uses Windows' Winsock2.
The library compiles successfully but when I try to run the Quake example it crashes. I located the line at which the program stops but i can't figure out how to solve the problem.
The program stops at the second call of the function getNextItem
class NetworkType {
public :
NetworkType();
~NetworkType();
template<class T>
void getNextItem(irr::core::vector3d<T>& data);
private:
typedef std::queue<std::string> Container;
Container items;
};
template<class T>
void NetworkType::getNextItem(irr::core::vector3d<T>& data) {
T X, Y, Z;
std::istringstream item(items.front());
// the program does not get here the second time it calls this function
items.pop();
item >> X;
item >> Y;
item >> Z;
data = irr::core::vector3d<T>(X, Y, Z);
}
and exactly at this line
std::istringstream item(items.front());
Can anyone tell me why does the program stop the second time it gets to this line ?
here is the link for the complete source code
I assume by "stops" you mean "crashes" in some fashion? Likely causes for a crash on the line in question are:
The NetworkType instance that is invoking the getNextItem() method is garbage (the this pointer is garbage or null). This could happen due to bad pointer math elsewhere, a premature delete or destruction of the instance, et cetera. This would manifest as a fault when the program attempted to access the items member.
The items container is empty. In these cases the return value of front() is undefined (since it is a reference) and the constructor for istringstream may be crashing. front() itself may be raising a debug/runtime check error as well depending on your compiler and its configuration.
Actually you might have a runtime error on this one if the dequeue is empty: MSDN deque
So just check the deque isn't empty before you try to pop a value from it.
if(items.size()>0)
{
//do things
}
else
{
//error deque empty
}
[edit] confounded std and (I guess) MSDN ( OP doesn't say) lib.
In my class I attempt to define 3 markers, one for errors, one for warnings, and one for breakpoints. This worked well when I was only attempting to define 2 markers, but for some reason the third of these markers doesn't appear when added to a line. If you switch the ordering of the definitions, it is always the third one that fails to appear when markerAdd() is called. The pixmaps are valid, and Scintilla's return values appear to be correct for both defining and adding markers. This is more of a general Scintilla question rather than a QScintilla question I believe, because QScintilla simply does some checks before calling the underlying scintilla code. I have no idea where to even begin in debugging this code. If anyone can shed some light on this, whether it is a known scintilla quirk or it is my fault, I would be eternally grateful.
m_errorIndicator = ui_editor->markerDefine(QPixmap(":/sourcefile/icon_set/icons/bullet_red.png"));
m_breakIndicator = ui_editor->markerDefine(QPixmap(":/sourcefile/icon_set/icons/bullet_black.png"));
m_warningIndicator = ui_editor->markerDefine(QPixmap(":/sourcefile/icon_set/icons/bullet_yellow.png"));
void SourceFile::on_actionAddBreakpoint_triggered()
{
qWarning() << "Added breakpoint to " << m_currentLine;
qWarning() << ui_editor->markerAdd(m_currentLine, m_breakIndicator);
m_breakpoints.append(m_currentLine);
}
void SourceFile::on_actionRemoveBreakpoint_triggered()
{
ui_editor->markerDelete(m_currentLine, m_breakIndicator);
m_breakpoints.removeAll(m_currentLine);
}
void SourceFile::clearProblems()
{
ui_editor->markerDeleteAll(m_errorIndicator);
ui_editor->markerDeleteAll(m_warningIndicator);
}
void SourceFile::markProblems(const QStringList& errors, const QStringList& warnings)
{
foreach(const QString& error, errors) {
int line = error.section(":", 1, 1).toInt();
if(--line < 0) continue;
ui_editor->markerAdd(line, m_errorIndicator);
}
foreach(const QString& warning, warnings) {
int line = warning.section(":", 1, 1).toInt();
if(--line < 0) continue;
ui_editor->markerAdd(line, m_warningIndicator);
}
}
There should be a yellow bullet next to the printf statement. If the warning and breakpoint definitions are switched, the yellow bullet will show up and the black bullet will disappear.
Aha! After days of looking, I finally found the problem.
ui_editor->setMarginMarkerMask(1, m_breakpointMarker);
Was being called in a setup method, which was causing funky behavior. Removing this fixed everything.