My drawing surface, to which an InkOverlay is attached,
also contains some UserControls.

I would like to use the same lasso-selection mechanism
that the InkOverlay offers to include those embedded
controls along with the ink that has been selected.

It is not difficult do figure out the controls that
are contained within the lasso stroke that InkOverlay
provides; it is also easy to move those selected controls
along with the selected ink.

But my problem is that I don't know how to show (mark)
the selected controls as being part of the overall selection.

The only (rather hackish) idea that I have at the moment
is to draw a (completely transparent?) rectangle of ink
around every embedded control of my drawing surface.
Then, presumably, this ink-boundary, if it gets selected,
will provide the required visual feedback for the controls
that have been selected. The link between that boundary
and the embedded control it marks as selected could be
provided by an ExtendedProperty of the boundary-stroke.

But maybe there is a more professional way to do it?

Thanks in advance for your comments on the hackish
idea sketched above or, even better, some other,
maybe less hackish sounding idea,

Christian

Hi Christian,

The InkOverlay (or the InkPicture) does not have the capability of selecting
child controls built-in, so you will have to write a bunch of code to make
that happen (as you have already realized).

Using a transparent stroke around child elements is a valid approach and I
have seen other apps that do exactly that.

Would switching to WPF be an option for you? In WPF we have built this
functionality right into the InkCanvas [1]. You can take a look at the
InkCanvas Clipboard sample in the SDK [2] to see how selection works in
InkCanvas. You can select ink or child elements or any combination of both.
You can move, resize or delete the selection as well copy/paste it via
clipboard. All that is built right into the InkCanvas control.

Thanks,
Stefan Wick

[1]
http://msdn2.microsoft.com/en-us/lib...inkcanvas.aspx
[2] http://msdn2.microsoft.com/en-us/library/aa972135.aspx


"Christian Stapfer" wrote:

> My drawing surface, to which an InkOverlay is attached,
> also contains some UserControls.
>
> I would like to use the same lasso-selection mechanism
> that the InkOverlay offers to include those embedded
> controls along with the ink that has been selected.
>
> It is not difficult do figure out the controls that
> are contained within the lasso stroke that InkOverlay
> provides; it is also easy to move those selected controls
> along with the selected ink.
>
> But my problem is that I don't know how to show (mark)
> the selected controls as being part of the overall selection.
>
> The only (rather hackish) idea that I have at the moment
> is to draw a (completely transparent?) rectangle of ink
> around every embedded control of my drawing surface.
> Then, presumably, this ink-boundary, if it gets selected,
> will provide the required visual feedback for the controls
> that have been selected. The link between that boundary
> and the embedded control it marks as selected could be
> provided by an ExtendedProperty of the boundary-stroke.
>
> But maybe there is a more professional way to do it?
>
> Thanks in advance for your comments on the hackish
> idea sketched above or, even better, some other,
> maybe less hackish sounding idea,
>
> Christian
>
>

"Stefan Wick[MS]" <StefanWickMS@discussions.microsoft.com> wrote in message
news:8C40F7EA-2AC2-438C-9173-209D1431F6FD@microsoft.com...
> Hi Christian,
>
> The InkOverlay (or the InkPicture) does not have the capability of
> selecting
> child controls built-in, so you will have to write a bunch of code to make
> that happen (as you have already realized).
>
> Using a transparent stroke around child elements is a valid approach and I
> have seen other apps that do exactly that.
>
> Would switching to WPF be an option for you? In WPF we have built this
> functionality right into the InkCanvas [1]. You can take a look at the
> InkCanvas Clipboard sample in the SDK [2] to see how selection works in
> InkCanvas. You can select ink or child elements or any combination of
> both.
> You can move, resize or delete the selection as well copy/paste it via
> clipboard. All that is built right into the InkCanvas control.
>
> Thanks,
> Stefan Wick
>
> [1]
> http://msdn2.microsoft.com/en-us/lib...inkcanvas.aspx
> [2] http://msdn2.microsoft.com/en-us/library/aa972135.aspx
>

Thank you very much for your quick and to the point answer.
Would be switching to WPF be an option for me?

Maybe I should explain what I am trying to achieve: I am porting a
distributed whiteboard (of a classical client-server type) from
Java2/Swing to C#, because I want the high-quality pen-input that a
tablet PC provides.
Um, well, "porting" may be something of an understatement: I hope
to substantially improve the whiteboard in the process. It's going to be
more of a rewrite, than a straightforward porting of the old whiteboard.

I have already ported the communication infrastructure (there, too,
I could have tried to use remoting services that Windows provides,
but have decided not to), and am slowly "growing" the new version:
currently I can write, move, resize, and delete ink, as well as embed
my user-controls in a distributed fashion. (Those user-controls need
to distribute their state too: but they do that on their own. Only
inserting,
moving, resizing and deleting them needs to be implemented in a way
that fits into the overall ink-handling framework)

Because I have to keep the various client whiteboards synchronzied
(not in all details, of course, but overall) I fear that InkCanvas might be
trying to do way too much for me. That is: InkCanvas might be trying to
do things which I would need to hook into (but perhaps cannot), in order
to distribute relevant information to the other client whiteboards. (In
fact,
I fear that I would have to implement a sizable portion of my application
*before* I can tell whether I can actually keep my various client
whiteboards
synchronized - or not...)

Also, I must admit, that I don't know much (if anything) about WPF, but
will now try to read up quickly on this. So this is just my first reaction
to
your suggestion. Maybe my first reaction to a completely new approach
is understandably somewhat negative, since I felt I was close to finishing
this project - or at least finishing the "feasibility study phase" of it -
successfully: and now everything seems quite open again.
I will likely need a good night's sleep in order to get over this
initial
frustration ;-)

As regards WPF: I already accept that my users need to have at least
Windows XP and version 2 of the .Net Framework. Increasing this
requirement to version 3 of the .Net Framework does not seem sooo
terrible to me. - Still, I must be careful: because those PCs will be
personal computers of typical high-schoolers and college/university
students...
Maybe in 5 years from now, using WPF might not be a (performance?)
problem, but I want the new version of my whiteboard *now* (or, rather:
very, very soon).

Regards, and thanks again for your reply,
Christian

>
> "Christian Stapfer" wrote:
>
>> My drawing surface, to which an InkOverlay is attached,
>> also contains some UserControls.
>>
>> I would like to use the same lasso-selection mechanism
>> that the InkOverlay offers to include those embedded
>> controls along with the ink that has been selected.
>>
>> It is not difficult do figure out the controls that
>> are contained within the lasso stroke that InkOverlay
>> provides; it is also easy to move those selected controls
>> along with the selected ink.
>>
>> But my problem is that I don't know how to show (mark)
>> the selected controls as being part of the overall selection.
>>
>> The only (rather hackish) idea that I have at the moment
>> is to draw a (completely transparent?) rectangle of ink
>> around every embedded control of my drawing surface.
>> Then, presumably, this ink-boundary, if it gets selected,
>> will provide the required visual feedback for the controls
>> that have been selected. The link between that boundary
>> and the embedded control it marks as selected could be
>> provided by an ExtendedProperty of the boundary-stroke.
>>
>> But maybe there is a more professional way to do it?
>>
>> Thanks in advance for your comments on the hackish
>> idea sketched above or, even better, some other,
>> maybe less hackish sounding idea,
>>
>> Christian
>>
>>

Stefan's right, this sounds like a killer app for InkCanvas. Run,
don't walk, to WPF!
-S

"Shawn A. Van Ness [MS]" <savanness******.com> wrote in message
news:1176142297.943005.176950@n76g2000hsh.googlegr oups.com...
> Stefan's right, this sounds like a killer app for InkCanvas. Run,
> don't walk, to WPF!
> -S

I suppose you are right: however, I could not resist
the temptation to try the approach that I was already
contemplating (using transparent border-strokes to
integrate embedded usercontrols into the lasso-selection
process implemented by InkOverlay) over the weekend.
I can now report that this approach was easy to
implement and works well.

Since I am still quite naive as regards WPF (coming
from Java2/Swing, and not being a fulltime, professional
software developer anymore), it will take me some time
to figure out what I can, and what I cannot do with
InkCanvas.
I will probably now try to finish my whiteboard port
to the point of making it already useful (I think it is,
even highly so: if only it would work as well on a
Tablet PC as it does on my Desktop machine), and only
then take a more serious look at InkCanvas (I have only
so much time for this). Having an application that
works (and only lacks a few "nice to have" features)
will buy me some time. Also: more time will now
be required to finish implementing those various
user controls, that I want to be able to embed (because
they are crucial to my application in the area of
math-tutoring). And that effort would be required
anyway, no matter whether I finally happen to switch
to an InkCanvas-based implementation, or not.

Right now, my most immediate concern is that
moving my application from the Desktop/SDK 1.7
environment to a real Tablet PC does not seem to be
without its problems (seeming differences between
those two environments). I was completely taken
by surprise with this. - This contrasts starkly with
my very positive experience with Java2: My old Java2
whiteboard works without ANY problems on Windows ME,
Windows XP, Mac-OSX, and Linux. - Not so with a
Tablet PC application that was developed on a Windows XP
desktop machine with the Tablet PC SDK Version 1.7
installed.

Regards,
Christian

What are the problems you are seeing when moving the app from the desktop
environemnt to the TabletPC?

Thanks,
Stefan Wick

"Christian Stapfer" <nil@dev.nul> wrote in message
news:3396a$461b138d$54497090$19469@news.hispeed.ch ...
> "Shawn A. Van Ness [MS]" <savanness******.com> wrote in message
> news:1176142297.943005.176950@n76g2000hsh.googlegr oups.com...
>> Stefan's right, this sounds like a killer app for InkCanvas. Run,
>> don't walk, to WPF!
>> -S
>
> I suppose you are right: however, I could not resist
> the temptation to try the approach that I was already
> contemplating (using transparent border-strokes to
> integrate embedded usercontrols into the lasso-selection
> process implemented by InkOverlay) over the weekend.
> I can now report that this approach was easy to
> implement and works well.
>
> Since I am still quite naive as regards WPF (coming
> from Java2/Swing, and not being a fulltime, professional
> software developer anymore), it will take me some time
> to figure out what I can, and what I cannot do with
> InkCanvas.
> I will probably now try to finish my whiteboard port
> to the point of making it already useful (I think it is,
> even highly so: if only it would work as well on a
> Tablet PC as it does on my Desktop machine), and only
> then take a more serious look at InkCanvas (I have only
> so much time for this). Having an application that
> works (and only lacks a few "nice to have" features)
> will buy me some time. Also: more time will now
> be required to finish implementing those various
> user controls, that I want to be able to embed (because
> they are crucial to my application in the area of
> math-tutoring). And that effort would be required
> anyway, no matter whether I finally happen to switch
> to an InkCanvas-based implementation, or not.
>
> Right now, my most immediate concern is that
> moving my application from the Desktop/SDK 1.7
> environment to a real Tablet PC does not seem to be
> without its problems (seeming differences between
> those two environments). I was completely taken
> by surprise with this. - This contrasts starkly with
> my very positive experience with Java2: My old Java2
> whiteboard works without ANY problems on Windows ME,
> Windows XP, Mac-OSX, and Linux. - Not so with a
> Tablet PC application that was developed on a Windows XP
> desktop machine with the Tablet PC SDK Version 1.7
> installed.
>
> Regards,
> Christian
>

"Stefan Wick[MS]" <swick@online.microsoft.com> wrote in message
news:%23g%232GA3eHHA.4916@TK2MSFTNGP06.phx.gbl...
> What are the problems you are seeing when moving the app from the desktop
> environemnt to the TabletPC?
>
> Thanks,
> Stefan Wick

I encountered the first problem of this type
when I tried to copy ink to the clipboard.
It took me some time to make sure that was
*not* because of a bug in my program (the
most likely caues, I thought at the time),
nor a simple question of not using properly
updated systems (both systems had the same
versions of .Net installed, and I ran Windows
Update on both machines to make sure that
*any* late correction of incompatibilities
between the 1.7 Tablet PC SDK, and the actual
software installed on my Tablet PC would be
installed. - But running Windows Update did
*not* solve this particular problem.

I posted a question in a .Net forum (probably
the wrong one), and didn't get an answer. By
googling around I found this:
http://support.microsoft.com/Default.aspx?kbid=900722
That web-page states that: "This problem occurs
because the Windows XP Service Pack 2 (SP2)
version of the Microsoft.Ink.dll file is *not*
compatible with Visual Studio 2005 CLR 2.0."
(As an aside: searching for Microsoft.Ink.dll
on my Tablet PC revealed that several applications
have their *own*, possibly different, copy of the
Microsoft.Ink.dll!)
Interestingly, at the time I encountered this
problem, I could not get this update (which
actually solved the ink-copy-to-clipboard
failure) through Windows Update: no, I had
to download and install it myself. Why is it,
that such an update does *not* get distributed
automatically, I wonder...

After this somewhat unpleasant experience,
I have come to expect trouble whenever I
try to move a program from my desktop
(development) environment to my Tablet PC.

And sure enough: Now, that I try to test
an early version of my distributed whiteboard,
problems crop up that I have *never* seen when
testing it on my desktop machine. (And I can
test even the distributed case rather well
on my desktop machine: because client whiteboards
and the server are connected only via sockets.)

Just two examples: The InkOverlay seems
to have a problem when lasso-selecting ink
(but, as I said: *only* when I run the whiteboard
client on the Tablet PC, it *never* shows this
problem when I run it on my desktop machine).
To be more specific: Initially I try to lasso a
bunch of strokes (a word, say), but that word
does not get marked as selected: altough I clearly
threw the selection-lasso around it.
I try again, say with individual letters,
and after some equally unsuccessful attempts
to lasso them, finally one letter *does* get
marked as selected. From then on, lassoing,
even the entire word (which failed initially)
works as expected. - Curious behavior, to say
the least...

Another problem is this: I embed images
in some of my user controls. This requires
serializing those images, and sending them
to the server (which, in turn, sends them
to all other client whiteboards). This
works without any trouble at all on my desktop
machine, but, for a reason that I have to
investigate further, fails on my Tablet PC.
(My guess is that this means that the client
on the Tablet PC, that receives a serialized
image, cannot properly deserialize it
(for whatever reason).)

Trouble is: I do not have a development environment
installed on my Tablet PC, but its seems I will
now have to install one. - However, if I install
a development environment: how sure can I be
that the resulting run-time environment for
my application is not *just* as different from
an ordinary Tablet PC environment as is my
desktop (development) environment?

Of course, a general caveat applies: I cannot
yet say, with reasonable certainty, that these
two (example) problems *do* go back to some
nasty incompatibility between my development
libraries on the desktop machine and the system
libraries on my Tablet PC: but my rough guess is
that something of this sort looks, to my eyes
at least, (unfortunately) very likely.

As I wrote, my experience, so far, when moving
from my desktop development environment to a
user's environment, has been much different with
Java2. With Java2 I never ever encountered a
problem that *only* showed up on the machine of
one of my (many) tutees. And what a big relief
this was: because I could not afford traveling
to a tutee (who may be living hundreds if not
thousands of miles away from me) just in order
to figure out what's different on his or her
machine...

Regards,
Christian

If you're writing CLR v2 apps for Windows XP, you'll need to get a fix
for Microsoft.Ink.dll:

Microsoft.Ink.dll CLR2.0 Update (KB900722)
Update for Tablet PC Microsoft Ink and .Net Framework 2.0
compatibility.

http://www.microsoft.com/downloads/d...displaylang=en

If you're running on Vista then the OS already has this patched
version.

What OS(es) are you running, on your desktop and tablet? (XP SP2 or
Vista?)

HTH,
-S

On Apr 10, 8:57 am, "Christian Stapfer" <n...@dev.nul> wrote:
> "Stefan Wick[MS]" <s...@online.microsoft.com> wrote in message
>
> news:%23g%232GA3eHHA.4916@TK2MSFTNGP06.phx.gbl...
>
> > What are the problems you are seeing when moving the app from the desktop
> > environemnt to the TabletPC?
>
> > Thanks,
> > Stefan Wick
>
> I encountered the first problem of this type
> when I tried to copy ink to the clipboard.
> It took me some time to make sure that was
> *not* because of a bug in my program (the
> most likely caues, I thought at the time),
> nor a simple question of not using properly
> updated systems (both systems had the same
> versions of .Net installed, and I ran Windows
> Update on both machines to make sure that
> *any* late correction of incompatibilities
> between the 1.7 Tablet PC SDK, and the actual
> software installed on my Tablet PC would be
> installed. - But running Windows Update did
> *not* solve this particular problem.
>
> I posted a question in a .Net forum (probably
> the wrong one), and didn't get an answer. By
> googling around I found this:http://support.microsoft.com/Default.aspx?kbid=900722
> That web-page states that: "This problem occurs
> because the Windows XP Service Pack 2 (SP2)
> version of the Microsoft.Ink.dll file is *not*
> compatible with Visual Studio 2005 CLR 2.0."
> (As an aside: searching for Microsoft.Ink.dll
> on my Tablet PC revealed that several applications
> have their *own*, possibly different, copy of the
> Microsoft.Ink.dll!)
> Interestingly, at the time I encountered this
> problem, I could not get this update (which
> actually solved the ink-copy-to-clipboard
> failure) through Windows Update: no, I had
> to download and install it myself. Why is it,
> that such an update does *not* get distributed
> automatically, I wonder...
>
> After this somewhat unpleasant experience,
> I have come to expect trouble whenever I
> try to move a program from my desktop
> (development) environment to my Tablet PC.
>
> And sure enough: Now, that I try to test
> an early version of my distributed whiteboard,
> problems crop up that I have *never* seen when
> testing it on my desktop machine. (And I can
> test even the distributed case rather well
> on my desktop machine: because client whiteboards
> and the server are connected only via sockets.)
>
> Just two examples: The InkOverlay seems
> to have a problem when lasso-selecting ink
> (but, as I said: *only* when I run the whiteboard
> client on the Tablet PC, it *never* shows this
> problem when I run it on my desktop machine).
> To be more specific: Initially I try to lasso a
> bunch of strokes (a word, say), but that word
> does not get marked as selected: altough I clearly
> threw the selection-lasso around it.
> I try again, say with individual letters,
> and after some equally unsuccessful attempts
> to lasso them, finally one letter *does* get
> marked as selected. From then on, lassoing,
> even the entire word (which failed initially)
> works as expected. - Curious behavior, to say
> the least...
>
> Another problem is this: I embed images
> in some of my user controls. This requires
> serializing those images, and sending them
> to the server (which, in turn, sends them
> to all other client whiteboards). This
> works without any trouble at all on my desktop
> machine, but, for a reason that I have to
> investigate further, fails on my Tablet PC.
> (My guess is that this means that the client
> on the Tablet PC, that receives a serialized
> image, cannot properly deserialize it
> (for whatever reason).)
>
> Trouble is: I do not have a development environment
> installed on my Tablet PC, but its seems I will
> now have to install one. - However, if I install
> a development environment: how sure can I be
> that the resulting run-time environment for
> my application is not *just* as different from
> an ordinary Tablet PC environment as is my
> desktop (development) environment?
>
> Of course, a general caveat applies: I cannot
> yet say, with reasonable certainty, that these
> two (example) problems *do* go back to some
> nasty incompatibility between my development
> libraries on the desktop machine and the system
> libraries on my Tablet PC: but my rough guess is
> that something of this sort looks, to my eyes
> at least, (unfortunately) very likely.
>
> As I wrote, my experience, so far, when moving
> from my desktop development environment to a
> user's environment, has been much different with
> Java2. With Java2 I never ever encountered a
> problem that *only* showed up on the machine of
> one of my (many) tutees. And what a big relief
> this was: because I could not afford traveling
> to a tutee (who may be living hundreds if not
> thousands of miles away from me) just in order
> to figure out what's different on his or her
> machine...
>
> Regards,
> Christian

Another difference between desktop and tablet environments... is not
a difference in the code or library versions, per se, but a difference
in *threading*.

When you use the mouse, all events are queud up on the main UI
thread. But when you use a stylus on a Tablet PC, some events are
fired from the "pen thread" (a background thread).

The symptoms you're describing ("sometimes the selection works" etc)
sound like race conditions.

When you handle events from InkOverlay, check the current thread, and
use Control.Invoke() to jump back to the main UI thread.

See Tip #1 here: http://msdn2.microsoft.com/en-us/library/ms810882.aspx

HTH,
-S


On Apr 10, 8:57 am, "Christian Stapfer" <n...@dev.nul> wrote:
> "Stefan Wick[MS]" <s...@online.microsoft.com> wrote in message
>
> news:%23g%232GA3eHHA.4916@TK2MSFTNGP06.phx.gbl...
>
> > What are the problems you are seeing when moving the app from the desktop
> > environemnt to the TabletPC?
>
> > Thanks,
> > Stefan Wick
>
> I encountered the first problem of this type
> when I tried to copy ink to the clipboard.
> It took me some time to make sure that was
> *not* because of a bug in my program (the
> most likely caues, I thought at the time),
> nor a simple question of not using properly
> updated systems (both systems had the same
> versions of .Net installed, and I ran Windows
> Update on both machines to make sure that
> *any* late correction of incompatibilities
> between the 1.7 Tablet PC SDK, and the actual
> software installed on my Tablet PC would be
> installed. - But running Windows Update did
> *not* solve this particular problem.
>
> I posted a question in a .Net forum (probably
> the wrong one), and didn't get an answer. By
> googling around I found this:http://support.microsoft.com/Default.aspx?kbid=900722
> That web-page states that: "This problem occurs
> because the Windows XP Service Pack 2 (SP2)
> version of the Microsoft.Ink.dll file is *not*
> compatible with Visual Studio 2005 CLR 2.0."
> (As an aside: searching for Microsoft.Ink.dll
> on my Tablet PC revealed that several applications
> have their *own*, possibly different, copy of the
> Microsoft.Ink.dll!)
> Interestingly, at the time I encountered this
> problem, I could not get this update (which
> actually solved the ink-copy-to-clipboard
> failure) through Windows Update: no, I had
> to download and install it myself. Why is it,
> that such an update does *not* get distributed
> automatically, I wonder...
>
> After this somewhat unpleasant experience,
> I have come to expect trouble whenever I
> try to move a program from my desktop
> (development) environment to my Tablet PC.
>
> And sure enough: Now, that I try to test
> an early version of my distributed whiteboard,
> problems crop up that I have *never* seen when
> testing it on my desktop machine. (And I can
> test even the distributed case rather well
> on my desktop machine: because client whiteboards
> and the server are connected only via sockets.)
>
> Just two examples: The InkOverlay seems
> to have a problem when lasso-selecting ink
> (but, as I said: *only* when I run the whiteboard
> client on the Tablet PC, it *never* shows this
> problem when I run it on my desktop machine).
> To be more specific: Initially I try to lasso a
> bunch of strokes (a word, say), but that word
> does not get marked as selected: altough I clearly
> threw the selection-lasso around it.
> I try again, say with individual letters,
> and after some equally unsuccessful attempts
> to lasso them, finally one letter *does* get
> marked as selected. From then on, lassoing,
> even the entire word (which failed initially)
> works as expected. - Curious behavior, to say
> the least...
>
> Another problem is this: I embed images
> in some of my user controls. This requires
> serializing those images, and sending them
> to the server (which, in turn, sends them
> to all other client whiteboards). This
> works without any trouble at all on my desktop
> machine, but, for a reason that I have to
> investigate further, fails on my Tablet PC.
> (My guess is that this means that the client
> on the Tablet PC, that receives a serialized
> image, cannot properly deserialize it
> (for whatever reason).)
>
> Trouble is: I do not have a development environment
> installed on my Tablet PC, but its seems I will
> now have to install one. - However, if I install
> a development environment: how sure can I be
> that the resulting run-time environment for
> my application is not *just* as different from
> an ordinary Tablet PC environment as is my
> desktop (development) environment?
>
> Of course, a general caveat applies: I cannot
> yet say, with reasonable certainty, that these
> two (example) problems *do* go back to some
> nasty incompatibility between my development
> libraries on the desktop machine and the system
> libraries on my Tablet PC: but my rough guess is
> that something of this sort looks, to my eyes
> at least, (unfortunately) very likely.
>
> As I wrote, my experience, so far, when moving
> from my desktop development environment to a
> user's environment, has been much different with
> Java2. With Java2 I never ever encountered a
> problem that *only* showed up on the machine of
> one of my (many) tutees. And what a big relief
> this was: because I could not afford traveling
> to a tutee (who may be living hundreds if not
> thousands of miles away from me) just in order
> to figure out what's different on his or her
> machine...
>
> Regards,
> Christian

"Shawn A. Van Ness [MS]" <savanness******.com> wrote in message
news:1176243298.587206.293460@q75g2000hsh.googlegr oups.com...
>
> If you're writing CLR v2 apps for Windows XP, you'll need to get a fix
> for Microsoft.Ink.dll:
>
> Microsoft.Ink.dll CLR2.0 Update (KB900722)
> Update for Tablet PC Microsoft Ink and .Net Framework 2.0
> compatibility.
>
> http://www.microsoft.com/downloads/d...displaylang=en

Well, yes, that is exactly the update that I downloaded
(manually, not through Windows Update, as this webpage
suggests!): and it immediately solved my problem with
trying to copy ink to the clipboard.
Now I have new problems when moving from the development
(desktop) environment to the target (Tablet PC) environment,
but, unfortunately, have lost confidence in the compatibility
of these two environments. If there is a hell for software
developers, it must be like this :-[

What annoys me in this case is not that updates occur,
but that they apparently are not distributed automatically.
Why is this? - Maybe because doing so may lead to other
problems?

> If you're running on Vista then the OS already has this patched
> version.
>
> What OS(es) are you running, on your desktop and tablet? (XP SP2 or
> Vista?)

Desktop: XP Professional, Version 2002, SP2.
Tablet PC: XP, Edition 2005, SP2.

Both have the latest versions of .NET Framework
1.1, 2.0 and 3.0 installed.

Regards,
Christian

"Shawn A. Van Ness [MS]" <savanness******.com> wrote in message
news:1176243699.327699.133610@b75g2000hsg.googlegr oups.com...
>
> Another difference between desktop and tablet environments... is not
> a difference in the code or library versions, per se, but a difference
> in *threading*.
>
> When you use the mouse, all events are queud up on the main UI
> thread. But when you use a stylus on a Tablet PC, some events are
> fired from the "pen thread" (a background thread).
>
> The symptoms you're describing ("sometimes the selection works" etc)
> sound like race conditions.
>
> When you handle events from InkOverlay, check the current thread, and
> use Control.Invoke() to jump back to the main UI thread.

Aha, yes (a light bulb goes on over my head): that sounds like a
*good* explanation.
I use event handlers for SelectionChanging, SelectionChanged,
StrokesDeleting, StrokesDeleted, SelectionMoving, SelectionMoved,
SelectionResizing, and SelectionResized.

Though I wonder why it is, that that background thread
does *not* call Invoke itself, if need be.
Also, I did not see any mention of this problem in either
http://msdn2.microsoft.com/en-us/lib...nkoverlay.aspx
or, for example,
http://msdn2.microsoft.com/en-us/lib...onchanged.aspx

>
> See Tip #1 here: http://msdn2.microsoft.com/en-us/library/ms810882.aspx

Great link! Thank you very much indeed. I will read this
as soon as possible (certainly before complaining any
more about the problems I have in this group).
Still, such *differences* between development environment
and target environment are a serious nuissance.
But at least I have a target (Tablet PC) available - and now,
thanks to your reply, a reasonable hypothesis for what
might be the root cause of these various strange behaviors
of my whiteboard client when it's being run on the target
machine.

Regards, and thanks again for your reply,
Christian

>
> HTH,
> -S
>
>
> On Apr 10, 8:57 am, "Christian Stapfer" <n...@dev.nul> wrote:
>> "Stefan Wick[MS]" <s...@online.microsoft.com> wrote in message
>>
>> news:%23g%232GA3eHHA.4916@TK2MSFTNGP06.phx.gbl...
>>
>> > What are the problems you are seeing when moving the app from the
>> > desktop
>> > environemnt to the TabletPC?
>>
>> > Thanks,
>> > Stefan Wick
>>
>> I encountered the first problem of this type
>> when I tried to copy ink to the clipboard.
>> It took me some time to make sure that was
>> *not* because of a bug in my program (the
>> most likely caues, I thought at the time),
>> nor a simple question of not using properly
>> updated systems (both systems had the same
>> versions of .Net installed, and I ran Windows
>> Update on both machines to make sure that
>> *any* late correction of incompatibilities
>> between the 1.7 Tablet PC SDK, and the actual
>> software installed on my Tablet PC would be
>> installed. - But running Windows Update did
>> *not* solve this particular problem.
>>
>> I posted a question in a .Net forum (probably
>> the wrong one), and didn't get an answer. By
>> googling around I found
>> this:http://support.microsoft.com/Default.aspx?kbid=900722
>> That web-page states that: "This problem occurs
>> because the Windows XP Service Pack 2 (SP2)
>> version of the Microsoft.Ink.dll file is *not*
>> compatible with Visual Studio 2005 CLR 2.0."
>> (As an aside: searching for Microsoft.Ink.dll
>> on my Tablet PC revealed that several applications
>> have their *own*, possibly different, copy of the
>> Microsoft.Ink.dll!)
>> Interestingly, at the time I encountered this
>> problem, I could not get this update (which
>> actually solved the ink-copy-to-clipboard
>> failure) through Windows Update: no, I had
>> to download and install it myself. Why is it,
>> that such an update does *not* get distributed
>> automatically, I wonder...
>>
>> After this somewhat unpleasant experience,
>> I have come to expect trouble whenever I
>> try to move a program from my desktop
>> (development) environment to my Tablet PC.
>>
>> And sure enough: Now, that I try to test
>> an early version of my distributed whiteboard,
>> problems crop up that I have *never* seen when
>> testing it on my desktop machine. (And I can
>> test even the distributed case rather well
>> on my desktop machine: because client whiteboards
>> and the server are connected only via sockets.)
>>
>> Just two examples: The InkOverlay seems
>> to have a problem when lasso-selecting ink
>> (but, as I said: *only* when I run the whiteboard
>> client on the Tablet PC, it *never* shows this
>> problem when I run it on my desktop machine).
>> To be more specific: Initially I try to lasso a
>> bunch of strokes (a word, say), but that word
>> does not get marked as selected: altough I clearly
>> threw the selection-lasso around it.
>> I try again, say with individual letters,
>> and after some equally unsuccessful attempts
>> to lasso them, finally one letter *does* get
>> marked as selected. From then on, lassoing,
>> even the entire word (which failed initially)
>> works as expected. - Curious behavior, to say
>> the least...
>>
>> Another problem is this: I embed images
>> in some of my user controls. This requires
>> serializing those images, and sending them
>> to the server (which, in turn, sends them
>> to all other client whiteboards). This
>> works without any trouble at all on my desktop
>> machine, but, for a reason that I have to
>> investigate further, fails on my Tablet PC.
>> (My guess is that this means that the client
>> on the Tablet PC, that receives a serialized
>> image, cannot properly deserialize it
>> (for whatever reason).)
>>
>> Trouble is: I do not have a development environment
>> installed on my Tablet PC, but its seems I will
>> now have to install one. - However, if I install
>> a development environment: how sure can I be
>> that the resulting run-time environment for
>> my application is not *just* as different from
>> an ordinary Tablet PC environment as is my
>> desktop (development) environment?
>>
>> Of course, a general caveat applies: I cannot
>> yet say, with reasonable certainty, that these
>> two (example) problems *do* go back to some
>> nasty incompatibility between my development
>> libraries on the desktop machine and the system
>> libraries on my Tablet PC: but my rough guess is
>> that something of this sort looks, to my eyes
>> at least, (unfortunately) very likely.
>>
>> As I wrote, my experience, so far, when moving
>> from my desktop development environment to a
>> user's environment, has been much different with
>> Java2. With Java2 I never ever encountered a
>> problem that *only* showed up on the machine of
>> one of my (many) tutees. And what a big relief
>> this was: because I could not afford traveling
>> to a tutee (who may be living hundreds if not
>> thousands of miles away from me) just in order
>> to figure out what's different on his or her
>> machine...
>>
>> Regards,
>> Christian
>
>

"Shawn A. Van Ness [MS]" <savanness******.com> wrote in message
news:1176243699.327699.133610@b75g2000hsg.googlegr oups.com...
>
> Another difference between desktop and tablet environments... is not
> a difference in the code or library versions, per se, but a difference
> in *threading*.
>
> When you use the mouse, all events are queud up on the main UI
> thread. But when you use a stylus on a Tablet PC, some events are
> fired from the "pen thread" (a background thread).
>
> The symptoms you're describing ("sometimes the selection works" etc)
> sound like race conditions.

Yes, yes, yes, indeed.

> When you handle events from InkOverlay, check the current thread, and
> use Control.Invoke() to jump back to the main UI thread.
>
> See Tip #1 here: http://msdn2.microsoft.com/en-us/library/ms810882.aspx

Just for completeness let me acknowledge that this
tip solved all my problems. - What? - All my problems?
- Well, a great many of them ;-)

Regards,
Christian


>
> HTH,
> -S
>
>
> On Apr 10, 8:57 am, "Christian Stapfer" <n...@dev.nul> wrote:
>> "Stefan Wick[MS]" <s...@online.microsoft.com> wrote in message
>>
>> news:%23g%232GA3eHHA.4916@TK2MSFTNGP06.phx.gbl...
>>
>> > What are the problems you are seeing when moving the app from the
>> > desktop
>> > environemnt to the TabletPC?
>>
>> > Thanks,
>> > Stefan Wick
>>
>> I encountered the first problem of this type
>> when I tried to copy ink to the clipboard.
>> It took me some time to make sure that was
>> *not* because of a bug in my program (the
>> most likely caues, I thought at the time),
>> nor a simple question of not using properly
>> updated systems (both systems had the same
>> versions of .Net installed, and I ran Windows
>> Update on both machines to make sure that
>> *any* late correction of incompatibilities
>> between the 1.7 Tablet PC SDK, and the actual
>> software installed on my Tablet PC would be
>> installed. - But running Windows Update did
>> *not* solve this particular problem.
>>
>> I posted a question in a .Net forum (probably
>> the wrong one), and didn't get an answer. By
>> googling around I found
>> this:http://support.microsoft.com/Default.aspx?kbid=900722
>> That web-page states that: "This problem occurs
>> because the Windows XP Service Pack 2 (SP2)
>> version of the Microsoft.Ink.dll file is *not*
>> compatible with Visual Studio 2005 CLR 2.0."
>> (As an aside: searching for Microsoft.Ink.dll
>> on my Tablet PC revealed that several applications
>> have their *own*, possibly different, copy of the
>> Microsoft.Ink.dll!)
>> Interestingly, at the time I encountered this
>> problem, I could not get this update (which
>> actually solved the ink-copy-to-clipboard
>> failure) through Windows Update: no, I had
>> to download and install it myself. Why is it,
>> that such an update does *not* get distributed
>> automatically, I wonder...
>>
>> After this somewhat unpleasant experience,
>> I have come to expect trouble whenever I
>> try to move a program from my desktop
>> (development) environment to my Tablet PC.
>>
>> And sure enough: Now, that I try to test
>> an early version of my distributed whiteboard,
>> problems crop up that I have *never* seen when
>> testing it on my desktop machine. (And I can
>> test even the distributed case rather well
>> on my desktop machine: because client whiteboards
>> and the server are connected only via sockets.)
>>
>> Just two examples: The InkOverlay seems
>> to have a problem when lasso-selecting ink
>> (but, as I said: *only* when I run the whiteboard
>> client on the Tablet PC, it *never* shows this
>> problem when I run it on my desktop machine).
>> To be more specific: Initially I try to lasso a
>> bunch of strokes (a word, say), but that word
>> does not get marked as selected: altough I clearly
>> threw the selection-lasso around it.
>> I try again, say with individual letters,
>> and after some equally unsuccessful attempts
>> to lasso them, finally one letter *does* get
>> marked as selected. From then on, lassoing,
>> even the entire word (which failed initially)
>> works as expected. - Curious behavior, to say
>> the least...
>>
>> Another problem is this: I embed images
>> in some of my user controls. This requires
>> serializing those images, and sending them
>> to the server (which, in turn, sends them
>> to all other client whiteboards). This
>> works without any trouble at all on my desktop
>> machine, but, for a reason that I have to
>> investigate further, fails on my Tablet PC.
>> (My guess is that this means that the client
>> on the Tablet PC, that receives a serialized
>> image, cannot properly deserialize it
>> (for whatever reason).)
>>
>> Trouble is: I do not have a development environment
>> installed on my Tablet PC, but its seems I will
>> now have to install one. - However, if I install
>> a development environment: how sure can I be
>> that the resulting run-time environment for
>> my application is not *just* as different from
>> an ordinary Tablet PC environment as is my
>> desktop (development) environment?
>>
>> Of course, a general caveat applies: I cannot
>> yet say, with reasonable certainty, that these
>> two (example) problems *do* go back to some
>> nasty incompatibility between my development
>> libraries on the desktop machine and the system
>> libraries on my Tablet PC: but my rough guess is
>> that something of this sort looks, to my eyes
>> at least, (unfortunately) very likely.
>>
>> As I wrote, my experience, so far, when moving
>> from my desktop development environment to a
>> user's environment, has been much different with
>> Java2. With Java2 I never ever encountered a
>> problem that *only* showed up on the machine of
>> one of my (many) tutees. And what a big relief
>> this was: because I could not afford traveling
>> to a tutee (who may be living hundreds if not
>> thousands of miles away from me) just in order
>> to figure out what's different on his or her
>> machine...
>>
>> Regards,
>> Christian
>
>

I've been fighting this battle for over a year. The update you're referring
to not only doesn't get distributed through Windows Update, but it's not
redistributable.

You can however do a "silent" install if you include the hotfix .exe in your
installer package and pass it a /Q switch I believe. Try it on the command
line with a /? to be sure.

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com


"Christian Stapfer" <nil@dev.nul> wrote in message
news:e2ea1$461c6051$54497090$7899@news.hispeed.ch. ..
> "Shawn A. Van Ness [MS]" <savanness******.com> wrote in message
> news:1176243298.587206.293460@q75g2000hsh.googlegr oups.com...
>>
>> If you're writing CLR v2 apps for Windows XP, you'll need to get a fix
>> for Microsoft.Ink.dll:
>>
>> Microsoft.Ink.dll CLR2.0 Update (KB900722)
>> Update for Tablet PC Microsoft Ink and .Net Framework 2.0
>> compatibility.
>>
>> http://www.microsoft.com/downloads/d...displaylang=en
>
> Well, yes, that is exactly the update that I downloaded
> (manually, not through Windows Update, as this webpage
> suggests!): and it immediately solved my problem with
> trying to copy ink to the clipboard.
> Now I have new problems when moving from the development
> (desktop) environment to the target (Tablet PC) environment,
> but, unfortunately, have lost confidence in the compatibility
> of these two environments. If there is a hell for software
> developers, it must be like this :-[
>
> What annoys me in this case is not that updates occur,
> but that they apparently are not distributed automatically.
> Why is this? - Maybe because doing so may lead to other
> problems?
>
>> If you're running on Vista then the OS already has this patched
>> version.
>>
>> What OS(es) are you running, on your desktop and tablet? (XP SP2 or
>> Vista?)
>
> Desktop: XP Professional, Version 2002, SP2.
> Tablet PC: XP, Edition 2005, SP2.
>
> Both have the latest versions of .NET Framework
> 1.1, 2.0 and 3.0 installed.
>
> Regards,
> Christian
>

The reason InkOverlay (or any component which does things on a background
thread) doesn't Invoke() the call to the main thread is twofold. 1) There
can technically be more than one UI thread if you have more than one message
loop running. So there isn't really a main thread, just one or more UI
threads. 2) Should it Invoke(), should it BeginInvoke(), should it do
anything? These are assumptions that the component author is not in a
position to make because the person developing the component can't predict
how your application will be responding to these events. If you don't need
to touch the UI then it's wasteful from a performance perspective to cross
threads. And if you need to do something and not return until your handler
is finished, you'd need to Invoke. But if you're not careful, using Invoke
can cause deadlocks. Therefore it's up to you.

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com


"Christian Stapfer" <nil@dev.nul> wrote in message
news:89ac5$461c6437$54497090$8518@news.hispeed.ch. ..
> "Shawn A. Van Ness [MS]" <savanness******.com> wrote in message
> news:1176243699.327699.133610@b75g2000hsg.googlegr oups.com...
>>
>> Another difference between desktop and tablet environments... is not
>> a difference in the code or library versions, per se, but a difference
>> in *threading*.
>>
>> When you use the mouse, all events are queud up on the main UI
>> thread. But when you use a stylus on a Tablet PC, some events are
>> fired from the "pen thread" (a background thread).
>>
>> The symptoms you're describing ("sometimes the selection works" etc)
>> sound like race conditions.
>>
>> When you handle events from InkOverlay, check the current thread, and
>> use Control.Invoke() to jump back to the main UI thread.
>
> Aha, yes (a light bulb goes on over my head): that sounds like a
> *good* explanation.
> I use event handlers for SelectionChanging, SelectionChanged,
> StrokesDeleting, StrokesDeleted, SelectionMoving, SelectionMoved,
> SelectionResizing, and SelectionResized.
>
> Though I wonder why it is, that that background thread
> does *not* call Invoke itself, if need be.
> Also, I did not see any mention of this problem in either
> http://msdn2.microsoft.com/en-us/lib...nkoverlay.aspx
> or, for example,
> http://msdn2.microsoft.com/en-us/lib...onchanged.aspx
>
>>
>> See Tip #1 here: http://msdn2.microsoft.com/en-us/library/ms810882.aspx
>
> Great link! Thank you very much indeed. I will read this
> as soon as possible (certainly before complaining any
> more about the problems I have in this group).
> Still, such *differences* between development environment
> and target environment are a serious nuissance.
> But at least I have a target (Tablet PC) available - and now,
> thanks to your reply, a reasonable hypothesis for what
> might be the root cause of these various strange behaviors
> of my whiteboard client when it's being run on the target
> machine.
>
> Regards, and thanks again for your reply,
> Christian
>
>>
>> HTH,
>> -S
>>
>>
>> On Apr 10, 8:57 am, "Christian Stapfer" <n...@dev.nul> wrote:
>>> "Stefan Wick[MS]" <s...@online.microsoft.com> wrote in message
>>>
>>> news:%23g%232GA3eHHA.4916@TK2MSFTNGP06.phx.gbl...
>>>
>>> > What are the problems you are seeing when moving the app from the
>>> > desktop
>>> > environemnt to the TabletPC?
>>>
>>> > Thanks,
>>> > Stefan Wick
>>>
>>> I encountered the first problem of this type
>>> when I tried to copy ink to the clipboard.
>>> It took me some time to make sure that was
>>> *not* because of a bug in my program (the
>>> most likely caues, I thought at the time),
>>> nor a simple question of not using properly
>>> updated systems (both systems had the same
>>> versions of .Net installed, and I ran Windows
>>> Update on both machines to make sure that
>>> *any* late correction of incompatibilities
>>> between the 1.7 Tablet PC SDK, and the actual
>>> software installed on my Tablet PC would be
>>> installed. - But running Windows Update did
>>> *not* solve this particular problem.
>>>
>>> I posted a question in a .Net forum (probably
>>> the wrong one), and didn't get an answer. By
>>> googling around I found
>>> this:http://support.microsoft.com/Default.aspx?kbid=900722
>>> That web-page states that: "This problem occurs
>>> because the Windows XP Service Pack 2 (SP2)
>>> version of the Microsoft.Ink.dll file is *not*
>>> compatible with Visual Studio 2005 CLR 2.0."
>>> (As an aside: searching for Microsoft.Ink.dll
>>> on my Tablet PC revealed that several applications
>>> have their *own*, possibly different, copy of the
>>> Microsoft.Ink.dll!)
>>> Interestingly, at the time I encountered this
>>> problem, I could not get this update (which
>>> actually solved the ink-copy-to-clipboard
>>> failure) through Windows Update: no, I had
>>> to download and install it myself. Why is it,
>>> that such an update does *not* get distributed
>>> automatically, I wonder...
>>>
>>> After this somewhat unpleasant experience,
>>> I have come to expect trouble whenever I
>>> try to move a program from my desktop
>>> (development) environment to my Tablet PC.
>>>
>>> And sure enough: Now, that I try to test
>>> an early version of my distributed whiteboard,
>>> problems crop up that I have *never* seen when
>>> testing it on my desktop machine. (And I can
>>> test even the distributed case rather well
>>> on my desktop machine: because client whiteboards
>>> and the server are connected only via sockets.)
>>>
>>> Just two examples: The InkOverlay seems
>>> to have a problem when lasso-selecting ink
>>> (but, as I said: *only* when I run the whiteboard
>>> client on the Tablet PC, it *never* shows this
>>> problem when I run it on my desktop machine).
>>> To be more specific: Initially I try to lasso a
>>> bunch of strokes (a word, say), but that word
>>> does not get marked as selected: altough I clearly
>>> threw the selection-lasso around it.
>>> I try again, say with individual letters,
>>> and after some equally unsuccessful attempts
>>> to lasso them, finally one letter *does* get
>>> marked as selected. From then on, lassoing,
>>> even the entire word (which failed initially)
>>> works as expected. - Curious behavior, to say
>>> the least...
>>>
>>> Another problem is this: I embed images
>>> in some of my user controls. This requires
>>> serializing those images, and sending them
>>> to the server (which, in turn, sends them
>>> to all other client whiteboards). This
>>> works without any trouble at all on my desktop
>>> machine, but, for a reason that I have to
>>> investigate further, fails on my Tablet PC.
>>> (My guess is that this means that the client
>>> on the Tablet PC, that receives a serialized
>>> image, cannot properly deserialize it
>>> (for whatever reason).)
>>>
>>> Trouble is: I do not have a development environment
>>> installed on my Tablet PC, but its seems I will
>>> now have to install one. - However, if I install
>>> a development environment: how sure can I be
>>> that the resulting run-time environment for
>>> my application is not *just* as different from
>>> an ordinary Tablet PC environment as is my
>>> desktop (development) environment?
>>>
>>> Of course, a general caveat applies: I cannot
>>> yet say, with reasonable certainty, that these
>>> two (example) problems *do* go back to some
>>> nasty incompatibility between my development
>>> libraries on the desktop machine and the system
>>> libraries on my Tablet PC: but my rough guess is
>>> that something of this sort looks, to my eyes
>>> at least, (unfortunately) very likely.
>>>
>>> As I wrote, my experience, so far, when moving
>>> from my desktop development environment to a
>>> user's environment, has been much different with
>>> Java2. With Java2 I never ever encountered a
>>> problem that *only* showed up on the machine of
>>> one of my (many) tutees. And what a big relief
>>> this was: because I could not afford traveling
>>> to a tutee (who may be living hundreds if not
>>> thousands of miles away from me) just in order
>>> to figure out what's different on his or her
>>> machine...
>>>
>>> Regards,
>>> Christian
>>
>>
>