Random problem with dropping methods on a workspace

Hello all,

For a long time now, I have been intermittently bitten by a corruption of
chunk data that I create by dragging methods to a workspace.  In particular,
the chunk for the new method is sometimes inserted near (but sadly not at)
the top of the workspace, resulting in corrupted chunks.  This happens
despite attempts to ensure that the caret and the drop location are below
all text in the workspace.  It seems to be worse with "large" amounts of
text in the workspace, though that's not a necessary condition.

Any ideas why this happens?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> For a long time now, I have been intermittently bitten by a corruption of
> chunk data that I create by dragging methods to a workspace.

I don't have a solution for your problem, only a suggestion for OA.

I don't know about anyone else, but I find that dragging a method to a
workspace to get a fileout is not what I'd want it to do.

As a way of getting a fileout, it is pretty clumsy (hard to get right even
without the bug that Bill sees -- I haven't noticed it myself).  Anyway, it's
not something I want to do very often; I doubt if I'd ever do it at all if I
didn't occasionally post code here.

OTOH, I think it'd be much more useful if dragging a method to a workspace just
pasted the selector at the drop point.

Anyone else agree ?  Anyone got a suggestion for a more practical UI for
creating fileouts of random clusters of methods ?

    -- chris

Bill/Chris,

I can't say I've noticed a problem with inserting text into a workspace via
drag-drop.  It always seems to be inserted at the caret position.

> I don't know about anyone else, but I find that dragging a method to a
> workspace to get a fileout is not what I'd want it to do.

I've got a goodie (IDB Method Filer) that works quite well for single
methods, it provides a "File Out" option on the Class/System/Method
Browser's Method menu and also provides a default filename.

> Anyone else agree ?  Anyone got a suggestion for a more practical UI
> for creating fileouts of random clusters of methods ?

None of the default browsers allow multiple method selection but it
shouldn't be too hard to add an IDE extension that provided a multiple
selection list of a classes methods and filed out all those selected to a
single file in chunk format.  It might also be possible to change the
standard MethodBrowser to allow multiple selections and fileouts across
classes?

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian,

> I've got a goodie (IDB Method Filer) that works quite well for single
> methods, it provides a "File Out" option on the Class/System/Method
> Browser's Method menu and also provides a default filename.

An IDE extension could work for me, but I would want to have a little more
control over the granularity.  For small changes, I add a dated comment to
my code (no extra tools required).  My version of "burn the disk packs" is
to file out anything that's about to get fried into a single file, and then
make the changes.  Granted, file time stamps would allow grouping of the
various methods, but it would turn into a LOT of files over time.  Something
like 'SQL obsolete 1-2004.st' is more helpful, especially since it gives a
single target for the CB :)


> None of the default browsers allow multiple method selection but it
> shouldn't be too hard to add an IDE extension that provided a multiple
> selection list of a classes methods and filed out all those selected to a
> single file in chunk format.  It might also be possible to change the
> standard MethodBrowser to allow multiple selections and fileouts across
> classes?

Try dragging a method category to a workspace.  Granted, the selection is
useful iff the the category matches what you want, but it's been quite
helpful.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Chris,

> As a way of getting a fileout, it is pretty clumsy (hard to get right even
> without the bug that Bill sees -- I haven't noticed it myself).  Anyway,
it's
> not something I want to do very often; I doubt if I'd ever do it at all if
I
> didn't occasionally post code here.

I use it a lot, but the right-drag menu could be extended to handle both
uses.


> OTOH, I think it'd be much more useful if dragging a method to a workspace
just
> pasted the selector at the drop point.

I agree that it would be nice to have a way to extract and paste selectors
by themselves.  However, I also find value in getting the method chunk.


> Anyone else agree ?  Anyone got a suggestion for a more practical UI for
> creating fileouts of random clusters of methods ?

As I mentioned in my reply to Ian, dragging a method category works great,
but only if the category covers what you want.  An IDE extension could pop
up a multiple selection list of all methods.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:c5esu6$go6$[hidden email]...
> Hello all,
>
> For a long time now, I have been intermittently bitten by a corruption of
> chunk data that I create by dragging methods to a workspace.  In
particular,
> the chunk for the new method is sometimes inserted near (but sadly not at)
> the top of the workspace, resulting in corrupted chunks.  This happens
> despite attempts to ensure that the caret and the drop location are below
> all text in the workspace.  It seems to be worse with "large" amounts of
> text in the workspace, though that's not a necessary condition.
>
> Any ideas why this happens?

Yes, if your "large" amount is >64K characters. TextEdit (and therefore all
text views which are subclasses, such as the RichEdit used by the workspace)
set the suggested drop target to the character nearest the mouse cursor as
it is moved over the view. The caret location is not material, since it is
only used if the suggested target is not set. The EM_CHARFROMPOS message is
used to locate the character under the drag cursor. If you search MSDN for
info on this you'll see that its parameter and return type vary depending on
whether it is sent to a normal edit control or a rich edit control - in the
case of the former the character index is returned in the low-order word of
its integer return value, i.e. it is limited to 16 bits. RichTextEdit
overrides #charNearestPosition: to deal with the change in parameter type,
but unfortunately it treats the return value as in the superclass and
discards the high 16 bits of the character position. This bug would tend to
result in a rather unpredictable drop location in larger workspaces. Its
easily corrected by deleting #lowWord from the method.

Well spotted, recorded as #1551!

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Bill Schwab wrote:
>
> > For a long time now, I have been intermittently bitten by a corruption
of
> > chunk data that I create by dragging methods to a workspace.
>
> I don't have a solution for your problem, only a suggestion for OA.
>
> I don't know about anyone else, but I find that dragging a method to a
> workspace to get a fileout is not what I'd want it to do.
>
> As a way of getting a fileout, it is pretty clumsy (hard to get right even
> without the bug that Bill sees -- I haven't noticed it myself).  Anyway,
it's
> not something I want to do very often; I doubt if I'd ever do it at all if
I
> didn't occasionally post code here.
>
> OTOH, I think it'd be much more useful if dragging a method to a workspace
just
> pasted the selector at the drop point.
>
> Anyone else agree ?  Anyone got a suggestion for a more practical UI for
> creating fileouts of random clusters of methods ?

Hmmm, well I do it rather a lot. There are also some changes in D6 that make
it more useful.
1) The 'changed' method category only includes those methods that have
changed since the owning class was last saved (either individually, or in
its package), not just all methods with source in the change log if the
owning class is marked as changed (as now). This makes it easy to drag all
relevent changes out in one go.
2) The method lists are now multi-select in all browsers.

Its certainly true, though, that one can construct more usable tools for
building fileouts. Watch out for something in D6 exploiting the new
Environment Browser that I have previously mentioned as a way of browsing
the content of a deployed application.

Regards

Blair

Blair,

> Yes, if your "large" amount is >64K characters. TextEdit (and therefore
all
> text views which are subclasses, such as the RichEdit used by the
workspace)
> set the suggested drop target to the character nearest the mouse cursor as
> it is moved over the view.

It seems to me that I have seen it in smaller workspaces, but your analysis
makes so much sense that I could simply be in error.  It is also possible
that Windows and I didn't agree on a drop location for some other reason -
unstable or dirty mouse, etc.


> The caret location is not material, since it is
> only used if the suggested target is not set. The EM_CHARFROMPOS message
is
> used to locate the character under the drag cursor.

As it should be.  I have an analogous problem in a GroupWise (not my idea
gang<g>) editor where caret locations pretty clearly are involved, so I
figured it couldn't hurt :)


> This bug would tend to
> result in a rather unpredictable drop location in larger workspaces. Its
> easily corrected by deleting #lowWord from the method.
>
> Well spotted, recorded as #1551!

Thanks for investigating.  Just to clarify, you want me to use the code
below?

Have a good one,

Bill

------------------

!RichTextEdit methodsFor!

charNearestPosition: aPoint
 "Answer the one based index of the character nearest aPoint within the
receiver.
 One might expect EM_CHARFROMPOS to work the same for rich text controls
 as it does for plain text controls, but no. Here we have to pass
 the address of a DWORD as the LPARAM. Note that, because of the word
 size return, this is limited to detection within 65K of text"

 | pt |
 pt := self clientRectangle constrain: aPoint.
 ^(self sendMessage: EM_CHARFROMPOS wParam: 0 lpParam: aPoint asParameter)
+1.
! !
!RichTextEdit categoriesFor: #charNearestPosition:!accessing!public! !

--
Wilhelm K. Schwab, Ph.D.
[hidden email]