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.
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 have the following code that starts a thread to send out commands. The thread takes a char * and int as arguments. In the "run" I use the pointer that is given by the constuctor. The code is:
MyThread::MyThread(char * payld, int payld_size)
{
payload_size = payld_size;
payload_p = payld;
}
void MyThread::run()
{
while(...)
{
sendCommand(payload_p, payload_size);
}
}
Unfortunately this doesn´t work and my application crashes when I try to use thread.start(). But when I change it to:
MyThread::MyThread(char * payld, int payld_size)
{
payload_size = payld_size;
payload_p = payld;
for(int i=0; i<payload_size; i++)
{
payload[i] = payld[i];
}
}
void MyThread::run()
{
while(...)
{
sendCommand(payload, payload_size);
}
}
The code does run and only crashes sometimes (looks pretty random to me). Can anybody Explain me why version one doesnt work and version two does? And any ideas on why the second code sometimes crashes? Could it be because the size of payload is not predefined (in the header file I defined it as
char payload[];
When I define it as:
char payload[10];
it seems to work better, but it is annoying to test since the crashes are pretty random.
instead of fiddling with char*, I would switch to QString (since you're using Qt). It takes a bit of learning, but it's almost mandatory to get code working smoothly in this framework. Then declare
QString payload;
and depending on sendCommand implementation, use one of the member functions QString to get the char*, like payload.toLatin1()
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.
Sorry for the vague title.
Currently, if a value is typed into a Q(Double)SpinBox which is out of its range (e.g. typing "100" when max is 90), the value is rejected and instead the last valid value is placed back into the SpinBox.
I want to change this behavior to allow typing out-of-range values which will be automatically corrected (to either the minimum or maximum), because otherwise it would be stupidly hard for the user to guess the value range. After studying the docs and source code of QT, I decided to subclass QSpinBox (will deal with Double variant later) into "QSpinBoxFS", and reimplement both methods mentioned in the title. Somehow though, this is having no effect at all, the behavior is still the same.
These are my methods:
QValidator::State QSpinBoxFS::validate(QString &input,
int &pos)
{
QIntValidator *validator = new QIntValidator();
return validator->validate(input, pos);
}
int QSpinBoxFS::valueFromText(const QString &text)
{
const int max = maximum();
const int min = minimum();
QString copy = text;
int dummy = 0;
QValidator::State state = validate(copy, dummy);
if (state == QValidator::Acceptable)
{
bool ok;
int num = locale().toInt(text, &ok, 10);
if (!ok) { goto bad_text; }
if (num < min) { return min; }
if (num > max) { return max; }
return num;
}
else
{
bad_text:
return (max > 0) ? min : max;
}
}
Of course, this is not really adequate to the pedantic checking done in QSpinBoxPrivate::validateAndInterpret, but I just want the basic concept working for now.
I tried changing validate() to always return Acceptable, but weirdly enough the resulting spinboxes would still behave in the old way.
Either a correction of my own methods or a different approach to this problem are welcome! Thank you for your time.
The signatures of the methods you're trying to reimplement are:
QValidator::State validate(QString & input,int & pos) const # <- const!
int valueFromText(const QString & text) const # <- const!
Both your methods are missing the const, so they are different methods and thus never called from the base class.
On a different note,
QAbstractSpinButton::setCorrectionMode(QAbstractSpinBox::CorrectToNearestValue)
can achieve somehwat similar results (typing values smaller than min will be corrected to min), although you are still prevented from typing values greater than max due to the validator. (And therefor it is insufficient for my needs, just leaving it here for reference.)
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...