"Ricardo" wrote in message
...
Since I have lots of calculations when my worksheet is loaded (it's loaded
from a DB), I opted to leave some of the calculations/data-filling in
background. I'm treating the UI problem with the trick of using a few
try-catchs and loop-sleep-while-unsuccessful (and it seems to work fine).
Any better suggestion?

From memory, I think the problem is that the user might be just about to
start typing in one cell, then you change the selection to another cell, and
they type the value in the wrong cell. Or something like that... basically
because all input (both user input and programmatic input) is serialised to
the UI thread, you are "fighting" with the user for access to the
spreadsheet.

Btw, is there any way to atomically execute a method? My thread which
populates formulas should not raise worksheet.change event. However I
shouldn't disable events (ThisApplication.EnableEvents) in the thread
since
the main UI thread should be raising those events on user input. I
thought
about atomically (maybe with monitors/locks) disabling events, updating
value/formula, and enabling events again... but was unable to figure out
if
it would work and how to do it. Maybe you (or someone) have an advice.
Of course i could just set cell_being_updated_in_background in a static
var
and then abort event-handler if that is the cell which raised the event...
not sure if it would be the best practice.

You would not need to bother with the locks because there is only one thread
executing at a time. (And you still don't solve the race condition, because
you are racing against the user, who doesn't really care what kind of locks
you have ;-) ). You could simply put the disable / enable inside a
try-finally if that's what you really wanted to do, but personally I think
the "I'm updating the cells so ignore events" flag is a better solution. You
might still miss an update though if the user changes a cell between your
call to disable the events and re-enable it; maybe you could also set
screenupdating to False to avoid that... but really you should avoid the
background update.

Maybe you can put up a progress bar instead while loading data? Or use the
RTD (Real Time Data) feature of Excel, although unfortunately that isn't
suported by VSTO.

Peter

--
Peter Torr - http://weblogs.asp.net/ptorr/
"Hands swinging high like a chopper in the sky" - A*Teens
This posting is provided "AS IS" with no warranties, and confers no rights
Samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

I've only read the TITLE of the thread...


I know that in VERY RARE circumstances
you must use FormulaLocal in user dialogs
where you ask the user to edit formulas.
but in 99,9% of code there's no need for the "local" derivates
of formulas or cell references.


Never ever use FormulaLocal property if you can avoid it.
Your application can only be used in 1 language version of excel.
AND you need to monitor the users international settings.

IN short:
Stick to Formula / FormulaR1C1, Forget FormulaLocal


keepITcool

< email : keepitcool chello nl (with @ and .)
< homepage: http://members.chello.nl/keepitcool


"Peter Torr \(MS\)" wrote:

"Ricardo" wrote in message
...
Since I have lots of calculations when my worksheet is loaded (it's
loaded from a DB), I opted to leave some of the
calculations/data-filling in background. I'm treating the UI problem
with the trick of using a few try-catchs and
loop-sleep-while-unsuccessful (and it seems to work fine). Any
better suggestion?