[Qt-interest] [BUG]QTextCuror::inserFrame() inserts block

[Israel Brewster]

On Apr 7, 2009, at 4:34 AM, Girish Ramakrishnan wrote:

> Israel Brewster wrote:
>> When calling QTextCursor::insertFrame(QTextFrameFormat), an extra  
>> empty
>> block is inserted before the frame, even though
>> QTextCursor::insertBlock() was never called. From what I have been  
>> able
>> to determine, there is no way to work around this behavior, meaning  
>> that
>> if you want to use a frame there will always be a blank line before  
>> it,
>> even if this is undesirable. There are, of course, any number of
>> situations in which one may want a blank line before a frame, but in
>> those situations you should call QTextCursor::insertBlock()  
>> explicitly.
>> No command should do something that was not explicitly requested  
>> without
>> some easy and obvious way to disable the functionality, even if the
>> function is "usually" desired - I would definitely consider this a  
>> bug,
>> unless I am just missing some way to disable it.
>>
>
> Can you show the code which reproduces the above? Are you saying that
> the below creates a block between foo and bar?:
> cur.insertText("foo");
> cur.insertFrame(QTextFrameFormat());
> cur.insertText("bar");
>
> The above works just fine in 4.4.

Well, I am using 4.5, but I  don't think this behavior has changed,  
and the code you sent exhibits the exact behavior I am talking about.  
Consider the following code block, which is primarily just a slightly  
expanded version of what you sent, with behavioral comments:

//Just get everything set up
QTextCursor cursor(calcEdit->textCursor());
QTextFrameFormat rightFormat;
rightFormat.setWidth(15); //keep it nice and narrow so it will fit  
next to the text easily.
rightFormat.setBorder(1);

//Make sure the cursor is at the beginning. This is probably  
unnecessary,
//as there hasn't been anything done yet, but I like to be safe and  
sure :)
cursor.movePosition(QTextCursor::Start);

//Insert an initial text block. This inserts the text at the top of  
the document, as expected.
//Good.
cursor.insertText("Te");

//Insert a second text block. This inserts the text immediately after  
the previous,
//Without inserting a new block. Again, Good -expected behavior.
cursor.insertText("st");

//Now insert a frame. The frame is inserted on the NEXT line, i.e. a  
block is inserted
//before the frame. BAD!
operation=cursor.insertFrame(rightFormat);

//Insert one more text for good measure. This is inserted inside the  
frame, as expected.
//Good
cursor.insertText("test2");


As you can see from the above cometary, when doing multiple  
insertText() calls, each one is inserted immediately after the  
previous one, in the same block, and the first insert occurs at the  
top line of the document. The result of the above two insertText()  
calls is the same as doing a single insertText("test") call on the  
first line. This is good - I have not asked for a new block, between  
the two inserts, and it has not given me a new block. insertFrame(),  
however, behaves differently - it always inserts itself on a new line  
(i.e. in a new block). Note how in the above code, the frame was  
inserted on the next line from the text, not immediately following it   
as I asked. While in many cases this is fine and saves code, in many  
other cases it is not, and there appears to be no way to disable it.  
What if you wanted multiple frames on the same line? What if (as in my  
case) you wanted text and the frame on the same line? What if you  
wanted a frame (perhaps right justified or something) at the TOP of  
the document, not one line down? Thus, bug.

Even aside from the fact that this is causing havoc with the  
application I am trying to write (I need a frame or similar  
immediately following some text on the first line of my document)  
there is a more fundamental problem with this: at no point in the  
above code was a new block requested (aside, perhaps, from within the  
frame, which may need to be a new block in the same way that an empty  
document is a new block), and yet, a new block was created. The insert  
went to the next line even though the programer did not ask it to go  
to the next line. If there was some way to disable this behavior, that  
might be ok - I can certainly see this being desired behavior much of  
the time. However, forcing an action that was not explicitly  
requested, with no way to work around it, is not acceptable behavior.  
To make it worse, this is inconsistent behavior - insertText() inserts  
the text within the same block, where as insertFrame moves to the next  
block (or makes a new block, or inserts immediately after the existing  
block, or some such similar looking  behavior).

>
> Note that a text document always contains a frame and a frame always
> contains a block. This means that if you insertFrame in an empty text
> document, it will appear as though an empty block has been inserted
> before it (when the fact is that the empty block was always present to
> start with).

But why isn't the frame inserted INSIDE the empty block? Why is it  
instead inserted AFTER? Yes, it has a block inside of it (of course),  
but that should have no effect on where the frame itself is inserted.

There is another possibility here - that I am not understanding the  
intended use of frames, and as such I am attempting to use them for  
something they were never intended for, in which case, of course, the  
observed behavior might be acceptable for their intended use. As such,  
I will hereby resubmit my original question which was initially ignored:

I need to generate what is in effect a two-column text document. The  
user is typing in the left column, and as they do so the program fills  
in various values in the right column, returning the cursor to the  
left column when done. This can be accomplished with frames, using a  
frame with the floatRight property. However, due to the above  
behavior, this leaves a blank line at the top of the document, which  
(apparently) can not be removed. As such, I either a) need a fix for  
this issue, b) need a work-around for this issue, or c) need an  
alternative approach to accomplish the desired behavior. Any of the  
above would be fine.

-----------------------------------------------
Israel Brewster
Computer Support Technician II
Frontier Flying Service Inc.
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7250 x293
-----------------------------------------------
>
> Girish