The widgets module is not optimized for mobile so there might be other issues at hand.

@MECoder said in How to write specific tag in existing XML using QXmlStreamWriter ?:

How can i write to a specific tag in an existing XML file without writing the complete XML fiel again?

You can't update an actual XML text file (just like you can't for any text file). You have to rewrite the whole new XML over the whole file.

Hi David,

There's also a docked dock widget.
When I first load an image and click on it the mousePressEvent of the top window is driven which in turn calls update() to drive paintEvent(). I have qDebug() code in the paintEvent code so I know the rectangles I want are being drawn.

Just to be sure:
From the window handle, it looks as if "Registering and Stacking" on the left is the dock widget.
The widget on the right is where the rectangles are being drawn, but not shown (I'll call it Sky-Widget)
When you undock the dock widget or resize the main window, the rectangles suddenly show up on the Sky-Widget.

stuff drawn in paintEvent is not visible

I have a widget (SelectRect) that (I am fairly sure) is on top of another widget that displays an image

I can't download anything from dropbox, so I don't know the code of SelectRect. But from the name, I would guess that a new SelectRect is instantiated each time the user draws a rectangle.
So here's a a poke in the dark:

The initial Z-order of Sky-Widget and SelectRect doesn't reflect what should be shown. The rectangles are in the background or even hidden (qDebug() << __FUNCTION__ << isVisible();at the end of paintEventwill tell). There is a code path somewhere in the application source, that sets the Z-order right. That code path is not entered after the rectangles have been drawn. The Z-order code path is, however, entered when the main window consumes an updateEvent: That's the case when it's being resized or the dock widget is undocked. Once the Z-order is correct, there are no more problems (Z-orders do not change automagically...).

=> somewhere in the code QWidget::show()or QWidget::raise() is probably called on SelectRect.
Throwing a few qDebugs into the neighborhood may bring some more insight.

Cheers
Axel

I use the following and it works:
pcoSplitter->setSizes({ pcoSplitter->size().width(), 0 });

@Zbigniew-Sch Do you set the position before or right after you call play()?
You need wait the player to load and buffer the media.
connect the mediaStatusChanged signal and set the postion when the status is QMediaPlayer::BufferedMedia.

@SGaist
The path is set in Qt like this:

d49ba81c-de15-4997-a340-24df8493afed-image.png

Is it okay?

@12bibi12
If you read @jsulm's linked thread properly you see it has nothing to do with .pro file or "makelist". It's an environment variable which needs to be set at runtime. If you use Creator it has a Run Environment you can alter.

@Damian7546 said in Edit TexEdit by click:

In my TextEdit I would like to add function. I would like to click to actual value and edit them. Now I have code like below:

Hi could you please be more explicit about what you actually want to do ? In my world, when you click any text editor, you enter the edit mode and then you can edit the value.

Of what I understand from your code, you want your input to be wholly selected, I'd rather pick for selectAll() method. Whereas to the property to be monitored, I'd rather pick for the TextEdit's onCursorVisibleChanged one, testing of course whether the cursor is actually visible or not.

By the way, your anchors seem very weird, as I understand it your horizontalCenter would be higher than the top.

Hi,

You should use InternalMove if you plan to only move things around within the same QTableWidget.

That said, you really should consider implementing delegates. As explained in the documentation, setCellWidget should only be used to show some static content.

@ankou29666 Thanks for your thoughts. I think all that is understood. The problem is that when we programmatically change the text this triggers onTextChanged, and thus causes nasty loops when the text changes cause text changes (which is what is what happens when there are multiple text blocks and they all need to be sync'ed with each other).

textEdited() breaks the cycle by allowing the signal to fire only when the user types new text, not just when the text is changed.

@fcarney Interesting idea