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.
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).
On Fri, Jun 3, 2011 at 7:58 AM, Jordan Justen <jljus...@gmail.com> wrote: > 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
> -- > You received this message because you are subscribed to the Google Groups "MonoXNA" group. > To post to this group, send email to monoxna@googlegroups.com. > To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
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. :)
On Sat, Jun 4, 2011 at 1:33 AM, Jordan Justen <jljus...@gmail.com> wrote: > 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
> -- > You received this message because you are subscribed to the Google Groups "MonoXNA" group. > To post to this group, send email to monoxna@googlegroups.com. > To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
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?
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.
> 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
> -- > You received this message because you are subscribed to the Google Groups "MonoXNA" group. > To post to this group, send email to monoxna@googlegroups.com. > To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
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.
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.
On Wed, Jun 8, 2011 at 9:49 AM, Jordan Justen <jljus...@gmail.com> wrote: > 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.
> 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
> -- > You received this message because you are subscribed to the Google Groups "MonoXNA" group. > To post to this group, send email to monoxna@googlegroups.com. > To unsubscribe from this group, send email to monoxna+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
