Clipboard corruption problem

[hs2]

@Clark: From time to time I'm still running into the clipboard corruption problem. (see http://community.slickedit.com/index.php?topic=1128.0)
The good thing: the result/symptom is always the same:
list-clipboards shows (at least one or more if I continue to copy-to-clipboard) entries like this:
':CHAR 1 * 79 0' or ':LINE 1 * 15 0'

On 'paste' I get the 'Text not selected' msg but the clipboard inheritance still works (the corrupted clip is transferred to the system clipboard as text) or if I select an entry which seems ok (copied before corruption occured) I get a 'newer' clip or junk for obvious reasons since the list is damaged.

Any idea ? It's quite annoying ... (Platform: v12.02 r7 - WXPSP2).

Edit: Found another workaround w/o the need of re-loading 'clipbd.e'.
If I copy sth. in other application to the system clipboard the list is magically repaired and I can continue to work although the older SE internal clips are still lost.

HS2

[hs2]

Seems that the workaround I've described before leads to some really bad results.
After exiting and restarting SE later it couldn't restore it's configuration (e.g. toolbars were not restored properly).
Thanks god I make daily config-backups. Otherwise there is no chance to recover from that maybe except manually repairing 'vrestore.slk'.
I assume the restoration of the partially corrupted clipboard list is causing the problem (I configured save/restore of the clipboards.)

But there are also some good news. There is a new command available as workaround: 'reset-clipboards'.
This is surely better than reloading 'clipbd.e' although it's not a solution since all clips are lost.
Hope it works (and I'm able to remember that) next time it happens...

HS2

[Clark]

Hmm.  I've haven't had any problems.  This will be really hard to track down without something reproducable.  In the past it's been EOL characters in the clipboards which have caused the problem.  I doubt that's the problem this time but you never know.

[hs2]

@Clark: Last time it happend quite often to me but I recognized that one of my own clipboard related macros was somehow involved.
So I re-checked my broken stuff and ... I've there was an inadvertent nested use of 'init_command_op()' !
Fixed it and I'm quite sure that my problem is gone now

Edit: It's not gone and I meanwhile think it's somehow related to the lineflags (selective display active) and using copy-word ... strange.
I'll send/post a report if I find sth. reproducible.

HS2

[hs2]

@Clark: Sorry to come back to this again - but there IS something strange/wrong with copy/paste seemingly in conjunction with 'selective display'. And it's really annoying if right in the middle of coding the clipboard goes crazy...

Just a few more observations:
- if I copy a line with lineflags=0x0 (selective display is not active at all for the buffer) and paste it in a/the same buffer the VSLF_LEVEL field of the newly inserted line is set (along with VSLF_INSERTED_LINE). I thought the level field is used to manage the selective display nesting levels only, right ?
- it happend a number of times that a 'copy-word -> paste into a different line' action changed the affected line into an 'imaginary buffer line'. After undo > reset lineflags 'manually' > paste (again) it worked as expected.

I hope it helps bit,
HS2

[Clark]

First, I should mention that some cases are ambiguous as to what should happen when pasting to/from selective display.  Line selections are work reasonably but make assumptions.  Pasting a word does seems odd.  It incremented the level.  I'm pretty busy at the moment but I try to find time to look into this.

[hs2]

Thanks a lot for taking care (sooner or later). And of course: First things first !
HS2

[Clark]

Lee is checking into the problem where you end up with imaginary lines.  The level number is overflowing it's bits into the other bit fields.  The first being the imaginary line bit.  It's easy to reproduce this bug by pasting a single word into a selective display line.

[hs2]

Right - that was also my assumption. So I'm looking fwd. to a hotfix
Thanks again, HS2

[Lee]

I have discovered some irregularities with paste in a selective display buffer, thanks to the new info you provided.  It appears that the line flags are being modified incorrectly.  I should be able to correct this issue, though it's not a hotfix candidate since the issue is not in the macro code.

[hs2]

Thanks god it seems that I've found a way to workaround the CHAR copy/paste problem.
(I guess CHAR copies to the '.clipboards' buffer could cause corrupted lines/entries also there.)
Last time it drove me crazy - almost every 5th copy action damaged the clipboard ring (working with selectively displayed buffers) and I decided to dig into it agaîn since it won't be hotfixed - unfortunately

HS2

[hs2]

Is it possible that there was workaround (or solution ?) silently implemented in 'clipbd.e' contained in the last hotfix r16 ?
It looks like that and I'm asking b/c otherwise I'd need to re-patch it. There rel.notes just refer to the named clip issue with VIM.
HS2

[Lee]

list_clipboards command was modified, which was the primary reason for issuing the hotfix revision, and a small update to the paste_next_clipboard command was included.  Both of those changes should be pretty self-contained.

In addition, a change did get included in the hotfix, on line 378, a call to clear the lineflags on the clipboard header line was added to the _add_clipboard_header function.  It's part of the fix to be will be included in the next release, along with changes to the binaries, That change could be affecting with your workaround, I did not test with your changes.

[hs2]

With my changes I try to revert back the inadvertently changed lineflags and I've verified that it works so far.
It was hard enough w/o knowing the REAL problem and how the clipboard system works so maybe there is some redundancy.
However, after applying the patch I didn't need to reset-clipboard anymore and the annyoing weird paste behaviour using the valued selective display was over too.
Well - I 've seen the change resetting the lineflags. That's the reason why I'm asking. I thought it's the more elegant version of my WA from the experts...
Did I get you right that this change is NOT related to the problem described in THIS thread and I need to re-apply my patch again ?
Thanks, HS2

[Lee]

Since the clipboard ring is actually a hidden buffer, the clipboard header line was "inheriting" line flags from the previous line of the clipboard (just like a normal editor buffer), as was the text being copied from it's source.  Clearing the lineflags on the clipboard header line helps somewhat, but it is still possible for the line levels and flags to be calculated incorrectly.  I've spent a good deal of time re-working the internal bits to "normalize" the line flags and selective display levels on copy operations for character selections, so that part will have to wait to the next release.