在 Windows Phone 7 上进行逻辑删除时，如何序列化 Lambda 和事件委托？
我一直在使用迄今为止有效的游戏状态管理示例。但我遇到了一个障碍：当墓碑出现时，屏幕是序列化的；唯一的麻烦是，MessageBoxScreen 有接受和取消的事件处理程序。
序列化这些内容的最佳方法是什么？我对使用表达式树做了一些研究，但这对于我想做的事情来说似乎过于复杂。
你如何将这些序列化？或者...您使用什么替代方法来保存包含委托的屏幕的状态？
I've been using the Game State Management sample which has worked so far. I've hit a snag though: when Tombstoning, the screens are serialised; the only trouble is, the MessageBoxScreen has event handlers for Accepted and Cancelled.
What's the best way to serialise these? I did a bit of research on using Expression Trees but this seemed overly complex for what I wanted to do.
How do you serialise these? Or... What alternative approach do you use to save the state of a screen that contains delegates?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我绝对会避免尝试序列化任何远程类似于 lambda 的东西，或者就此而言，命名方法。请记住：您存储的是状态，而不是其他任何内容。
根据您对这些委托的各种分配的范围和广度，您可能能够摆脱维护
Dictionary、序列化键并在反序列化后查找回调的麻烦。另一件需要考虑的事情——我不是专家，但从字里行间看，听起来好像你正在努力墓碑一个非常临时的模式对话框。你真的想要那个吗？您最好在用户返回时将其直接带到高分表或对话框中的任何内容。
I'd definitely steer clear of attempting to serialize anything remotely resembling a lambda, or for that matter, named methods. Remember: you're storing state, and nothing else.
Depending on how far and wide your various assignments to these delegates are, you might be able to get away with maintaining a
Dictionary<String, WhateverDelagateType>, serializing the keys and looking up the callbacks after deserialization.Another thing to consider--I'm no expert, but reading between the lines it sounds as if you're working towards tombstoning a very temporary modal dialog. Do you really want that? You might be better off bringing your user right to the high scores table, or whatever follows your dialog, on his/her return.
我决定反对这个。相反，我坚持将游戏流程视为一种“流程图”。
该流程图在代码中声明，并具有属性“LastShape”和“LastResultFromShape”。
在我的代码中，我每次都会重建流程图定义，如下所示：
流程从上到下，因此“AddLine”与最后添加的形状相关。
墓碑化后，我只需读取最后一个形状和最后一个结果，并据此决定流程图中的位置。
I decided against this. I instead persists game flow as a kind of 'flow chart'.
The flow chart is declared in code and has properties 'LastShape' and 'LastResultFromShape'.
In my code, I rebuild the flow chart definitions each time, something like this:
The flow goes from the top down, so 'AddLine' relates to the last shape added.
After tombstoning, I just read the last shape and the last result and decide where to go in the flowchart based on that.