Digital Workshop

I have a layout where a Frame is moved horizontally.

There is an odd problem. Observed in Preview mode.
If the User enters some text and selects a portion of the text, the Frame containing the Text Input object will drag other objects with it when moved. Sort of a 'cloning' effect.

Only happens when text is selected.

Can someone verify this problem on their system? (attached imp)
Any ideas why this might be happening and how to eliminate it?

My system uses nVidia Geforce GO 7700. DirectX is ver. 10, I think.

And the award for the most bizarre bug goes to....Lar!

Morning Lar,

I've seen the cursor problem before - it's present in our IKIQ software - but the lovely effect of half scrolling text is new to me.

Tested it on ATI and nVidia and got the same effect. It seems to be something to do with the transparency of the frame but also setting the publication to run in a window solves the issue.

The cursor issue is just quirky but could be worked around if necessary.

Mack

Thanks Mack for the sanity check. Glad I don't have to troubleshoot graphics/drivers today.



Not so fast. I changed the Frame_22 from 'no background' to a solid color. At first glance it appears the ghosting/grabbing is not happening. But take a closer look. At the very bottom edge of the frame you can detect a few pixels picked up from the text line I presume. Again if no text in the TextInput object is selected, the frame moves without the effect.

I hope I don't have to put the pub to show in a Window.

Sorry Lar,

Wasn't clear. I know that the border of the frame still cuts through the text. What I mean was that it seems to be a transparency issue because of the impact it has on the publication not that it solves the problem.

Out of interest, is the reason why frame22 cannot be sent to the back?

Mack

Are you asking '...any reason why... cannot'?

I do use the hide and show to sequence through this frame and a few other framesets. So this frame starts off appearing much the same as the others, User does some work just as on the others. But at certain times I want that work area expanded while retaining existing work. So sliding the frame provided both area and continuity imho.

BTW this sample pub doesn't show the real pub's details: has a working area on the right side also, several control buttons, headers, etc... which get 'ghosted'.

Back on the issue/oddity. I also find now that once the frame is moved right, a User does not have normal use of the cursor for Text Input. The only thing that can be done is position the cursor at the end and append text. Cannot select text, cannot place the cursor between words. So this is not the trivia problem I thought initially.

As for cursor problems... this oddity is one problem. There was posted another problem a few months ago. The cursor would change to a "horizontal resizing" cursor <--> for example, when crossing boundaries to a chapter-window page. (not just horiz... could be any direction). I still have that too. That is awkward and a nuisance since the cursor does not revert to its standard shape when that View/Chapter page is closed.

I was wondering why the frame22 needed to be above the other objects on the page as below them, the problem vanishes.

Also you could setselection(-1) before the slide.

I've played with it some more and it seems that the text-input-box (TIB) is complete buggered the minute it's moved - if D&D which was looked at a few weeks ago.

I had wondered whether it was related to another Opus oddity that I've been looking at whether the objects dimensions aren't updated and perhaps the because the dimensions are out the selection doesn't know where to work from - but this doesn't seem the case.

It's almost like the position of the TIB is fixed at the start of execution and there is nothing that can be done about. Very frustrating!

As for the last issue of the cursor - this is yet another quirk, but I seem to remember that you can solve this by doing something like placing a frame over / under the page / panel and specifying the cursor in the frame's properties.

Mack

Do these issues only appear on Vista, or on XP as well?

Paul

*I acknowledge in advance this is a rather long discussion. Am eager for a solution at the core of this.


In my real pub, 'frame22' is on a content page and 'the other objects' are on a master page. These objects are Nav buttons and design/texture vectors, etc. So, 'yes' needs to be this way or some similar way to make the Pub manageable.
[Edit Lar:] When the "underlying objects" reside on a Master Page, then the Frame22 will drag a 'cloned' or 'ghosted' image of them (within frame boundaries that is). And, the 'underlying objects' remain 'complete' (not ripped or separated as the Text Line in the sample pub here shows).
[2nd Edit:] It turns out that pseudo-cloning does not just happen because objects were on a Mast Pg. I had some other SetLayer() things going on... which is why the basic oddity morphed.


Yes thanks. I tried that as a workaround. Added it to Arrow Buttons actions. It actually works. However the I-beam cursor is then positioned off-Object... where the TIBox WAS. But workaround prevents the "hijacking ghosting". Good!! Thx.
And there is still the "crippled" TIB. (discussed below)


Yes this is a real disappointment. Not a show stopper however. I am now thinking of major workarounds. Just cannot directly do what I thought I could achieve.



( Hey DW! ) What I observed when I started looking into this errant behavior was this. As soon as I selected a section of text in the Text Input Box, some PERIPHERALLY VISIBLE background colors changed slightly as if that Frame and its Vector objects now had the Focus. What I mean is my Frame22 itself had no background, is larger than TIBox, and contains other irregular shaped Vectors. Those were visible where the TIBox did not cover them. Once TIB selection was made, the whole area of the containing Frame22 and those Vectors seemed to 'be selected' or 'have focus'... but of course the unmoved TIB does have the effective focus/cursor for text inputing.
I don't know if this corroborates your observation or is something different.



What do you mean 'fixed'? It's broken. Ditto, V.Frustr'g.


I'll play/test that when my mind in not boggled or kidnapped.

Hi Paul,

Yes in XP and I assume Vista as Lar's using that.

Lar,

By fixed, I meant that publication recognises the original position of the TIB even if it's moved. (not fixed as in mended)

[EDIT] REMOVED DAFT STATEMENT - AND GONE FOR COFFEE [/EDIT]


I can see why the TIB box might be considered a fixed item as it seems unlikely that it would need to be dragged and dropped BUT you've hit the same problem that any animation that shifts elements of the screen such as increasing space or a menu system renders the TIB broken.

Additionally, a project we worked on before Christmas was due to use cloned TIB, but thankfully we opted for a different method as this would have hit the same brick wall - as I assume that the program thinks the selection for the TIB is back with the original not the clone.

I'm glad some of the solutions worked.

Mack

P.S I'll email DW today. I've got some elearning project coming up that will make greater use of the TIB and it would be good if a solution emerged.

Yes interesting. I verified this for an image obj. But to be clear... the GetObjectDimensions() does accurately reflect position changes after a Move(x,y,1).

However, if I put that Object in the Frame 22 and move the frame, 'GOD()' reports relative to the original baseline and does not detect the traverse due to the frame move. An easy way to see this is to put the Object in the frame but off-page to the left. At runtime, moving the frame brings object in view. But GOD position info shows a minus-X value. An animation that Moves the Obj directly reflects changes from that off-page position. I hope we'll saying the same thing.

I'm wondering if this is something to do with the newer Plexus version, or was it always there in Opus?

I'm going to go have a nice dinner Friday and hopefully it will be repaired for Saturday.

Okay, am going to take foot out of mouth now! The object was in a frame. I always forget that GOD and Getposition work differently.

I don't know about a good meal, I think a drink might be necessary for this week. Well, I'm going to go back to my problem that does involved GOD but I think it's still clear as you say that something is a miss with the TIB.

One problem at a time today - I think

Mack

I've found another aspect of this problem (sliding frame results in handicapping other objects) -- when I put a Video object in the Frame and start Play then move the Frame, the Video object is clipped or cropped. Not a problem if vid started after move. Video was set ChromaKey I think.

It does not matter whether that Frame is at the top or the bottom in the Organizer, same issue.

I have not tested this in published pub, only Preview.