Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-vcm-dev] IMoveDeleteHooks

We decided not to use IMoveDeleteHook because of the lack of batch
processing. We are using resource delta mechanism instead. One problem that
we still have open is you can get a delta notificatin while some other
dialog (like create a new file dialog) is still open and if you try to open
your own dialog it is impossible to get a reference to the correct parent.
The best you can do in this case is to use the default parent which is the
current workbench window.  The result is your dialog is shown between
current active dialog and the main window. Yet worse, if your dialog blocks
the thread that opened it, the original dialog has no chance to close until
your dialog closes. Wondering is there a safe way to open a dialog and do a
remote operation on delta notification or may be we are doing something that
is inherentrly wrong...

Another thing I was curious about is what do you do in the move/delete hook
when there is some sort of repository IO exception, say the connection is
broken or so. Does this mean that local move will also fail? Sounds like a
major inconvenience if someone uses a dial-up to access his repository, or
even worse is on a trip with no means to connect to a repository at all.
Probably a better solution would be to accumulate move/delete delta
information and apply it during next synchronization operation, whatever it
is, or may be even a combination of both...

-Vladimir.

----- Original Message -----
From: "Adam Terrenzio" <adam.terrenzio@xxxxxxx>
To: "IBM-Vcm-Dev (E-mail)" <platform-vcm-dev@xxxxxxxxxxx>
Sent: Tuesday, November 05, 2002 10:53 AM
Subject: [platform-vcm-dev] IMoveDeleteHooks


> We are currently working on a full implementation of the interface.
> Completing the implementation of the Move/Delete hooks has been
interesting
> attempting to get an acceptable user experience.
>
> The moveFile()/deleteFile() methods only give you one file at a time and
> does not allow for batch processing.  That means that if the user selects
50
> different files, and then moves them to the same location, we would get 50
> different moves, each possibly requiring a prompt from our version control
> product for decisions on how to handle it in the repository.
>
> Our prompts have "OK to ALL" buttons on them that allow the user to have a
> single interaction apply to the entire set of selections (this greatly
> reduces the number of dialogs), but we can't use this in this case because
> we only get the actions one at a time.  What we need is the ability to
hood
> in at a point where we are given the entire selection (api doesn't appear
to
> have this point) or a way to 'simulate' having been called with the entire
> selection.  Is there a way to batch them and then process all at once?  I
> could not find a gesture such as MovesComplete to capture (listen to).  It
> would be no problem caching the first answer, the question would be - how
to
> know when everything is done to reset the question? Is there a way to gain
> access to the selection and then (when we would at least know the
first/last
> element) execute the repository operation for that set?
>
> How would something like this behave within the scope of Refractoring?
Does
> it also construct a Selection object which then gets processed or is it
more
> of a one-at-a-time processing model?  Can I just get an array of IFiles
> (source, dest pairs) instead of them singly?
>
> Thanks,
> Adam.
>
> Adam Terrenzio
> Software Developer, MKS Inc., www.mks.com
> Tel: (519)883-3216
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
>


Back to the top