@SGaist said in Add Qlabel as item in QTableview:

QStyledItemDelegate

Ok..I'll try with that.
from google search maybe this kind of output it will give, which maybe as our requirement.

Else, I have some lengthy approach..implement custom label with mousepressevent handled which emits the object name and add these custom labels, 20 in HLayout and add hlayouts in a vlayout...

Thanks!

@SGaist Thank you very much for the quick reply.

I've removed both the horizontal and vertical layout boxes and everything works exactly as I want.

Sometimes newbies make life more complicated for themselves than it needs to be!

Thanks again!

no, decrese the font size and see if it works. then you'll know whether you can change font size at all. If it works then that should be a hint as to why you cannot increase the size.

@mrjj I tried your code, here's the result:

I resolve it.

I setted font of text as property of QML Text component.
(Like font.family : parent.fontfamily)

and on Qt 5.7's QML, there are no enough options to control font properties.

so, I moved to C++ side and set a whole application font.

QFont font = someClass.getLangFont();
//set property of font instance here
// such as hinting policy, style etc.
QApplication::setFont(font);

now it looks very cleary...

thank you..

Why are they not ?

The Basic Drawing Example shows that. In your case, you'd likely just have to paint your image using the correct scaling information.

@SGaist got it.

Thanks for your answer, unfortunately this part of my code is executed in a class that inherits from QMainWindow, I don't have access to the QApplication.

Edit:

It works using QCoreApplication::processEvents() instead.

Hi,

What do you mean by regular string ?

If it comes from the Windows API, you should then consider using QDir:: fromNativeSeparators.

@SGaist
I tried very hard. But, still am not satisfied with the implementation. And now am feeling helpless.
If I set set, fixedsize for QLabel, then scroll bars won't appear if I use zoomout/zoomin.
My question is why QLabel won't shrink back after changing size through Qsplitter. I tried all the combinations of sizepolicy and nothing has worked so far

Hi
should that not be pointer ?
QRubberBand rubberBand; -> QRubberBand * rubberBand;
(since you do rubberBand= new QRubberBand(QRubberBand::Rectangle,this) )

that would explain all 3 errors.

What you need in fact is a QFormLayout (a subset of the grid layout) where you can insert the pairs of widgets with QFormLayout::addRow.

@Chris-Kawa I got the mistake, I was keeping size policy fixed due to which allignment has no effect on the text label.

Thank you everyone. It got solved

Hi Jamie,

Could you put the relevant parts in a minimal compilable example?

otherwise we only can guess...

Ok,

I'll mark this as solved.

I wasn't able to do it with QGraphicsDropShadowEffect, and creating all images twice and including them in the rcs-file is simply a no go.

Therefore I create a function, that draws a shadow - all 4 sides - around the the QImages, either at startup or during runtime.

Here it is, in case anyone else needs something like it.

QImage drawShadow(QImage img) { //Condition img allready has a transparent border 4 Pixel in this case //Create new Img with same Size QImage imgBGround(img.size(), img.format()); //Fill it with transparency QPainter p(&imgBGround); QPen pen; pen.setStyle(Qt::NoPen); p.setPen(pen); p.setRenderHint(QPainter::Antialiasing); p.fillRect(QRect(0,0,img.width(), img.height()), QColor(255,255,255,0)); //Draw Rounded Rectangle as Shadow QPainterPath path; path.addRoundedRect(QRect(0,0,img.width(), img.height()),15,15); p.fillPath(path,QColor(110,152,226)); p.drawPath(path); //Draw Original Img over background p.drawImage(0,0,img); return imgBGround; }

I had some similar problem. My QMenu wasn't adjusting to a dynamically changed size of QWidgetAction. I have found this thread http://www.qtcentre.org/threads/26291-QWidgetAction-resize-in-QMenu and suggested workaround worked for me. Qt 5.9.5.

QResizeEvent re (QSize(1, 1), size()); qApp->sendEvent(this, &re); adjustSize();

Where this is a pointer to QMenu object.
Fake resize event forces all menu items size recalculating and adjustSize() recalculates it.
I hope it will help to anyone else.

Hi and welcome to devnet,

What variable do you want to update ?

Why do you think you need a thread for that ?

On a side note, update is a QWidget non virtual slot so you can't use that name.

In any case you should call labelTimr->setText("TIME :" + timeValue) to update the content of your QLabel.

Hi,
QPainter can draw a QImage. So you can for example create a new Widget, subclass for QLabel for example if you want and reimplement paintEvent. Like this you work all the time with your QImage without creating another one.
And better you can only update the region that changed, no need to refresh everything. I did not try it but it should work.
Sincerely

I changed it to this code:

QWidget *f=QApplication::activeWindow(); //if(mf!=NULL) if(f->windowTitle()=="User-Management") { //QMessageBox::warning(this, tr("Login failed"), "UserMng", QMessageBox::Ok); QLabel* lbl = f->findChild<QLabel*>("lblRFIDdata"); //mf->processData(output); lbl->setText(output); return; }

and the label change. really thanks.

Hi,

You have two memory leaks now. There's no need to allocate pixmap nor painter on the heap.

i.e:

QPixmap pixmap(ui->label->width(), ui->label->height()); QPainter painter=(&pixmap); painter.drawPixmap(100, 0, 50, 50, QPixmap("C:/Users/user/Pictures/a.png")); painter.drawPixmap(0, 0, 100, 100, QPixmap("C:/Users/user/Pictures/1.png")); painter.end(); ui->label->setPixmap(pixmap);

@mrjj

Wow, super. That actually solved it.

Thank you so much for your response, your time and your help. I really appreciate it.

Thanks.

Best regards,
Anton

I guess you are right. I will work on this without the Threads. Thank you for your help!

I solved it.
Before setting selection, do clearFocus() and only then setFocus().
So, change these 2 lines:

label->setFocus(); label->setSelection(INDEX , 1);

to:

label->clearFocus(); label->setFocus(); label->setSelection(INDEX , 1);

That's very weird.

Thanks for the reply. This is using intel graphics, and unfortunately your workaround does not help. After your message, I've tested the same code from a newer live image and also on my more up-to-date laptop (which has similar hardware) and I can not reproduce the issue in either of these cases. On the affected machine, I tried updating the intel driver and mesa, but this did not solve it, so I guess it probably needs the kernel or qt packages updated as well. Unfortunately, this is not an option at this point.

I've worked around the issue by re-implementing paintEvent() to do something like the following

if (no_pixmap_set) { pos = calculateTextPosition() QPainter::drawText(pos, text); return; } QLabel::paintEvent(event);

Which seems to work just fine. In fact, re-implementing the paintEvent has given me the chance to animate the image changes which looks pretty nice, and it will be easy to simplify the code a bit when all my machines are fully updated and the glitch is gone.

Thanks again!

Hi and welcome to devnet,

Rather than using extern variables you should encapsulate your ssh related code in a class and use it from your GUI. It will be easier to interface with it.

Hope it helps

@sohyun

oh, so it was not the image that was broken?
super
Nice day to you too

Something like:

QIcon icon = style()->standardIcon(QStyle::SP_DialogOkButton); QPixmap pixmap = icon.pixmap(QSize(64, 64));

Glad it worked! You can add [Solved] - in the title of this post to mark it has solved ;)

@Yaseen
Well there are many samples and I stumbled on this one a day where I typed
Widget in the search field to see all samples for Desktop / not Qt Quick . :)

Further debugging shows that it works in my project on Windows but not when I compile for eLinux.
Must be something that does not work with Qt 4.6.3 with DFB 1.4.3 and Fusion on eLinux.

thanks again, sorry if my question was dumb

Do you have Qt configured to use that display ?

Okay, so I studied @Chris-Kawa's answer again. And what hit me like a bolt of lightning is that what I was dreaming of doing is virtually nonsensical. Now I really understand what he was saying.

This is what I wished to make happen (when I was naive :D):

The background timer's timeout event, issues an update() command which draws immediately into the screen (like magic), which in turn, triggers a ~17ms single-shot timer. When that timer's timeout occurs, the text shown on the screen is cleared immediately (again magic). This keeps on looping till the user stops the background timer.

This is what actually happens:

Issue an update() command that "draws" the text (text is NOT shown yet). The single-shot timer (@~17ms) is triggered.
...probably some milliseconds elapsed (let this be x ms). At the vertical refresh moment, text becomes visible on screen. (this is damn fast, so I'm ignoring this interval)
...probably some milliseconds elapsed (let this be y ms) The single-shot timer has ended after ~(x+y) ms and a command to clear the text has been issued.
...probably some milliseconds elapsed (let this be z ms). At the vertical refresh moment, text is cleared from the screen. (ignoring this interval again)

So, the user sees the text for about (x+y+z+k) ms where, k is the sum of the additional milliseconds used in actually doing that stuff. Now, x+y+z+k ms is almost always not equal to the desired interval.
That's why, this process sucks, big time.

Now, this is the best that can happen:

Wait for the background timer to end. After it ends, as soon as a refresh cycle occurs, issue the command to draw the text. At the next refresh cycle, the text will be drawn to the screen. After the text is drawn, start the single-shot timer. After the timer has ended, issue the command to remove the text. Wait for the next refresh cycle. At the next refresh cycle, the text will be removed from the screen. Now, start the background time. Now go to the first step.

Visualizing the process,

Now, it is evident that showing the text exactly for 15ms is impossible using the previous method. But at least we can make sure that we don't show that more than ~32ms. And that's good news. At least in my case.

Now, the point is how to achieve that. I don't know. But I'll find you and I'll kill you, nay implement you.