MonoXna mouse scroll

[Jordan Justen]

It doesn't seem possible to implement the mouse scroll feature with
the current project layout. Only the game dll (SdlGameHost) will be
able to see the scroll events, but there is not a public interface
whereby this information can be passed to the Mouse class in the main
framework dll.

The only solution I can think of would be to create a MonoXna dll that
both assemblies could depend on. I don't think this would break the
XNA compatible interface of the public dlls. It seems very similar to
the dependency on the Tao assemblies.

Any other ideas to fix this?

Thanks,

-Jordan

[Lars Magnusson]

Hi Jordan

This is not an issue, since the Microsoft.Xna.Framework.Game assembly
references the Microsoft.Xna.Framework assembly. This makes it
possible to update the MouseState.ScrollWheelValue without any
problems. I can look into implementing it (if you don't have the urge
to do it yourself).

-lavima

> --
> You received this message because you are subscribed to the Google Groups "MonoXNA" group.
> To post to this group, send email to mon...@googlegroups.com.
> To unsubscribe from this group, send email to monoxna+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
>
>

[Jordan Justen]

On Fri, Jun 3, 2011 at 01:53, Lars Magnusson <lav...@gmail.com> wrote:
> This is not an issue, since the Microsoft.Xna.Framework.Game assembly
> references the Microsoft.Xna.Framework assembly. This makes it
> possible to update the MouseState.ScrollWheelValue without any
> problems. I can look into implementing it (if you don't have the urge
> to do it yourself).

MouseState.ScrollWheelValue 'set' is marked as internal.

Also, the state needs to be updated in the Mouse class, since the
MouseState is retrieved from there.

I got it to work by using Mouse.WindowHandle, but that is not a
reasonable solution. :)

-Jordan

[Lars Magnusson]

We can get around the internal issue with the following attribute;
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx

I haven't used it before myself, but it should do the trick.

-lavima

[Jordan Justen]

On Sat, Jun 4, 2011 at 03:10, Lars Magnusson <lav...@gmail.com> wrote:
> We can get around the internal issue with the following attribute;
> http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx

I was able to make this work, but only after I regenerated the keys for
Microsoft.Xna.Framework.Game.

When looking into the examples for InternalsVisibleTo, I noticed that
the length of xna.pub in monoxna seems longer. Usually the public key
is 160 bytes, whereas the current ones are 288 bytes. When I
regenerate the keys, the length is 160 bytes as well.

Do you know why there is this difference, and why it appears to break
InternalsVisibleTo?

Thanks,

-Jordan

[Lars Magnusson]

The keys was created by timpambor at one point (along with delayed
signing in the mono framework), but I've never been able to get it to
work properly. I haven't had the time to investigate myself, but I
think there might be an open issue relating to the subject.

-lavima

[Jordan Justen]

On Sun, Jun 5, 2011 at 23:09, Lars Magnusson <lav...@gmail.com> wrote:
> The keys was created by timpambor at one point (along with delayed
> signing in the mono framework), but I've never been able to get it to
> work properly. I haven't had the time to investigate myself, but I
> think there might be an open issue relating to the subject.

After further investigation, the issue seems to be a bug in mono where
perhaps only 1024 bit keys work properly. The XNA keys are 2048 bit.

Here is the commit the mono commit that should fix things:
https://github.com/mono/mono/commit/8dab9d20d4d5a

And the bug report:
https://bugzilla.novell.com/show_bug.cgi?id=664618

The developer of the commit above confirmed that this should fix the
2048 bit key issue, and that it should be released in mono 2.10.
Unfortunately that means a lot of systems will not have the fix for
quite some time.

Once again, I think it would be good to consider a separate assembly
that the public XNA DLLs could depend on.

Thanks,

-Jordan

[Lars Magnusson]

First off, thanks for investigating this problem.

But, if we are going to continue discussing this subject, you should
create a new post with a more suitable subject.

-lavima