Drag & Drop

  • Thread starter Thread starter Michi
  • Start date Start date
Michi said:
wow. much code for this little thing...

thanks for the link/sample project
Click to expand...

The raw win32api is much more verbose than the .net wrappers written around
it. Whenever you need something not provided by the wrappers you have to do
it the old way, which as you saw requires much more userwritten code. The
..net classes do all of that too, it's just behind the scenes for you.
 
Danny said:
Does this mean it can't be done with no/low-trust apps like those run via
ClickOnce? :(
Click to expand...

As soon as you don't have permissions to do interop, you're out of luck.


Oliver Sturm
 
Oliver Sturm said:
As soon as you don't have permissions to do interop, you're out of luck.
Click to expand...

Doh!

I understand that some MS controls (like the treeview) work like this
anyway - is this just a case of "if microsoft wraps it, it doesn't need
interop permission"?
 
Danny said:
Doh!

I understand that some MS controls (like the treeview) work like this
anyway - is this just a case of "if microsoft wraps it, it doesn't need
interop permission"?
Click to expand...

I don't know exactly what you're seeing with the TreeView, I don't
normally use it. I just had a quick look and I saw that the TreeView does
in fact have this line on its WndProc:

[SecurityPermission(SecurityAction.LinkDemand, Flags=SecurityPermissionFlag.UnmanagedCode)]

This is .NET 2, so it might have been changed from earlier versions - but
I would think the TreeView couldn't possibly work in an environment where
the UnmanagedCode permission is not granted.

Now, once the TreeView can actually be used, it's a common control - so
the code that calls into the imagelist APIs could be outside of the parts
we can see in .NET code. And this code would no longer be caught by the
..NET interop layer, either.

Finally, for the interop thing there's a special attribute called
SuppressUnmanagedCodeSecurityAttribute - guess what that one does... look
here (MSDN) for a discussion: http://shrinkster.com/8cx

And then, even more finally, nobody would keep you from implementing
similar functionality yourself, without using the imagelist API. This
would probably be a bit difficult as soon as you want the drag images to
be displayed while data is being dragged between controls (as opposed to
only above one control) - just the reason why MS chose to implement this
stuff in as unlikely a place as the imagelist API.


Oliver Sturm
 
Oliver Sturm said:
I don't know exactly what you're seeing with the TreeView, I don't
normally use it
Click to expand...
This is .NET 2, so it might have been changed from earlier versions - but
I would think the TreeView couldn't possibly work in an environment where
the UnmanagedCode permission is not granted.
Click to expand...

That's what I thought, but not for the reason you gave. My original question
is answered on the page you posted, I understand the security a lot more.
However, you said:
I saw that the TreeView does in fact have this line on its WndProc:
[SecurityPermission(SecurityAction.LinkDemand,
Flags=SecurityPermissionFlag.UnmanagedCode)]
Click to expand...

Now that confused me. For two reasons... One, I don't understand why it's
needed - surely the treeview is pretty safe?! Two - does this mean my
planned ClickOnce application can't use the TreeView?

Where did you get that info from? Is it based on the beta2 and could it
change? Or was it from msdn? :(

Danny
 
Danny said:
That's what I thought, but not for the reason you gave. My original
question is answered on the page you posted, I understand the security a
lot more. However, you said:
I saw that the TreeView does in fact have this line on its WndProc:
[SecurityPermission(SecurityAction.LinkDemand,
Flags=SecurityPermissionFlag.UnmanagedCode)]
Click to expand...

Now that confused me. For two reasons... One, I don't understand why it's
needed - surely the treeview is pretty safe?! Two - does this mean my
planned ClickOnce application can't use the TreeView?
Click to expand...

Probably the TreeView is pretty safe, but apparently they didn't see this
as a valid reason to work around .NET code security - which I generally
find a good thing.

I haven't tried this and I also haven't used ClickOnce, apart from a
cursory test. But I think you can actually run ClickOnce applications that
require all kinds of permissions client side; what I meant was you'll have
to make sure you have these permissions because the TreeView certainly
seems to require them. To acquire the needed permissions, you'll need to
use a feature called "permission elevation". Here's a blog article with a
quick explanation:
http://blogs.msdn.com/shawnfa/archive/2003/11/14/57031.aspx

But you can also find a lot of other docs, also on MSDN, by googling for
"permission elevation".
Where did you get that info from? Is it based on the beta2 and could it
change? Or was it from msdn? :(
Click to expand...

This information is based on beta 2 and I got it by looking at the sources
for the TreeView with Reflector.



Oliver Sturm
 
Oliver Sturm said:
But I think you can actually run ClickOnce applications that require all
kinds of permissions client side; what I meant was you'll have to make
sure you have these permissions because the TreeView certainly seems to
require them. To acquire the needed permissions, you'll need to use a
feature called "permission elevation". Here's a blog article with a quick
explanation: http://blogs.msdn.com/shawnfa/archive/2003/11/14/57031.aspx
Click to expand...

That's right, but your user would get a box (I hope) saying something like
"this app wants to do something dangerous. Please click no" if I want access
for unmanaged code. The ActiveX dialog doesn't seem to put people off, so
I'm hoping with ClickOnce it's a bit more obvious just what you're giving
permission for!

Besides, even if I *can* get it, I don't want a user to have to give my app
access to do "anything" just for a treeview :-(

Anyways, I'll wait for the final release, and try it :-)

This information is based on beta 2 and I got it by looking at the sources
for the TreeView with Reflector.
Click to expand...

Excellent - I was sure there was something out there, but I googled and
couldn't find it! Reflector it is! (duh, how obvious is that!)
:-)
 
Back
Top