c语言如何编写截屏程序_截屏视频：为Optimus Mini三键盘编写托管的.NET插件-CSDN博客

c语言如何编写截屏程序

Here's a screencast demoing writing Managed .NET Plugins for the Optimus Mini Three Keyboard.

这是一个截屏视频演示，为Optimus Mini三键盘编写了托管.NET插件。

I'm a fan of the Optimus Mini-Three Keyboard for its potential. It's a harbinger of things to come, like someday a complete keyboard with screens for keys. Their hardware is wonderful. But, as a design shop with a specialization in hardware, not software, their software plugin model leaves much to be desired.

我喜欢Optimus迷你三键盘的潜力。这是即将发生的事情的预兆，例如总有一天，一个带有按键屏幕的完整键盘。他们的硬件很棒。但是，作为一家专门从事硬件而非软件的设计商店，他们的软件插件模型还有很多不足之处。

When I did my video on an Optimus Mini Three post in managed code, I ended up P/Invoking into their library, bypassing their plugin model and opting instead for a command line experience. Bummer, right?

当我在托管代码的Optimus Mini Three帖子中制作视频时，我最终将P / Invoking到了他们的库中，绕过了他们的插件模型，而是选择了命令行体验。兄弟，对吗？

The Optimus Configurator is pretty, to be sure, but it's programming model is obtuse and trapped in the C++ world. And not the nice OOP C++ world, the nasty part of that world.

可以肯定的是， Optimus Configurator很漂亮，但是它的编程模型是呆板的，被困在C ++世界中。并不是很好的OOP C ++世界，而是那个世界的讨厌部分。

The "implement these dozen virtual methods that tunnel strings via magic indexes" world:

“实现通过魔术索引传送字符串的十几个虚拟方法”世界：

virtual BOOL Paint(int button, HDC hdc) = 0;

// to collect INFO_* values from plugin 
virtual LPARAM GetInfo(int index) = 0;

 virtual BOOL Paint( int button, HDC hdc) = 0;

// to collect INFO_* values from plugin 
virtual LPARAM GetInfo( int index) = 0;

Meh. When your unmanaged C++ plugin gets called, the configuration app will call your GetInfo at least 20 times, passing in different magic numbers to get information about your plugin like name, webpage, version, etc. Not only are there these internal semantics to grok, there's a whole get/setProperties state bag thing to manage as well.

嗯当您的非托管C ++插件被调用时，配置应用会调用您的GetInfo至少20次，并传递不同的幻数以获取有关您的插件的信息，例如名称，网页，版本等。不仅这些内部语义值得关注，还有一个完整的get / setProperties状态包要管理。

It's a common pattern for plugins though, especially when you as the host want to provide persistence to your plugins. The Windows Live Writer plugin model is similar...I had to maintain state for my Insert Amazon Links WLW Plugin via the same pattern.

但是，这是插件的常见模式，尤其是当您作为主机要为插件提供持久性时。 Windows Live Writer插件模型类似...我必须通过相同的模式来维护我的Insert Amazon Links WLW插件的状态。

On the other hand, the Paint stuff is very clever, actually. You get an HDC (handle to a device context) passed in, you paint to it, and they handle getting the resulting image over to the Optimus via their USB to Serial Bridge.

另一方面，Paint的东西实际上非常聪明。您将传入一个HDC(到设备上下文的句柄)，对其进行绘制，然后他们将生成的图像通过USB到串行桥传输到Optimus。

But, their plugins aren't managed code, and I believe that this more difficult model explains the fact that while the device is selling well, there are only (as of the writing of this post) three 3rd party plugins.

但是，他们的插件不是托管代码，我相信这个更困难的模型可以解释一个事实，即该设备销售情况良好，但截至本文撰写之时，只有三个第三方插件。

Harald Röxeisen went off (he says after reading my post...Cool!) and has released an alpha of a .NET library for Optimus Support. However, rather than supporting managed plugins in the Optimus Configurator, he's written his own configurator from scratch in .NET, and built a plugin model on top of that. It's basic, but a fantastic start. He proves my point about writing plugins, as even his alpha include THREE all new plugins written against his managed API. Excellent.

HaraldRöxeisen离开了(他读完我的文章……很酷！他说)，并发布了Optimus支持的.NET库的alpha版本。但是，他不是在Optimus Configurator中支持托管插件，而是在.NET中从头开始编写了自己的配置器，并在此基础上构建了一个插件模型。这是基本的，但很棒的开始。他证明了我关于编写插件的观点，因为即使他的Alpha也包括针对他的托管API编写的所有三个新插件。优秀的。

For me, I've done the inverse of Harald, and got managed plugins to work inside the existing configurator. After my last post, I got great ideas from Matt Davis of DocumentCommand and Jason Copenhaver. Jason's was managed/unmanaged C++ that would provide a bridge, and Matt's used COM and the .NET COM Interop stuff as a middleman. For me, Matt's was faster as I know that stuff pretty well.

对我来说，我做过Harald的逆事，并获得了可管理的插件来在现有配置器中工作。在上一篇文章发表之后，我从DocumentCommand的Matt Davis和Jason Copenhaver获得了很棒的想法。杰森(Jason)的托管/非托管C ++提供了桥梁，马特(Matt)则使用COM和.NET COM Interop作为中间人。对我来说，Matt的速度更快，因为我知道这些东西相当不错。

Here's the general idea...Matt's shim implements the C++ virtuals that the configurator expects and calls CoCreateInstance on a known ProgId, in my example it's "Optimus.Nothing." Could be whatever. You'll need one shim and one ProgId per managed plugin as far as I can see. That call to CoCreateInstance is actually activating a .NET assembly that is implementing Matt's COM interface (that we might want to make even more COMish) created via TlbImp. Since we're .NET, the runtime and we get loaded, and wackiness ensues.

这是一般的想法... Matt的填充程序实现了配置程序期望的C ++虚拟函数，并在已知的ProgId上调用CoCreateInstance，在我的示例中为“ Optimus.Nothing”。可能是什么。据我所知，每个托管插件将需要一个垫片和一个ProgId。对CoCreateInstance的调用实际上是在激活.NET程序集，该程序集实现了通过TlbImp创建的Matt的COM接口(我们可能想制作更多COMish)。由于我们是.NET，因此需要运行时和加载，随之而来的是古怪。

We're in a no-man's land between managed and unmanaged code (and I'm sure we're leaking like a sieve) but we do things like Marshal.StringToHGlobalAnsi(managedString).ToInt32(); and

我们处于托管和非托管代码之间的无人区(而且我敢肯定我们会像筛子一样泄漏)，但我们会执行Marshal.StringToHGlobalAnsi(managedString).ToInt32();之类的事情。和

static int i = 0;
public int Paint( int button, IntPtr HDC)
{
    i++;
    DebugWrite(button);
    using (Graphics g = Graphics.FromHdc(HDC))
    {
        Brush b = ((i % 2 == 0) ? Brushes.Blue : Brushes.Red);
        g.FillRectangle(b, new Rectangle(0, 0, 96, 96));
    }
    if (i > 100) i = 0;
    return 1;
}

...for example. But, happily, we seem to not be noteworthy because the Mini Configurator loads us just fine.

...例如。但是，令人高兴的是，我们似乎并不值得一提，因为Mini Configurator可以很好地加载我们。

I've approached Harald and perhaps we'll figure out a better bridge for .NET plugins where I could write a plugin that supports his managed API and use it in either his configurator, or the original configurator from Optimus. If I'm going to be promoting writing these plugins, we'll want the interface to hide a lot of the dispatchy stuff, more like the plugin model Bryan Batchelder and I did for the USB Security Key Fobs.

我接触过Harald，也许我们会为.NET插件找到一个更好的桥梁，我可以编写一个支持他的托管API的插件，并在他的配置器或Optimus的原始配置器中使用它。如果我要促进编写这些插件的工作，我们将希望该界面隐藏很多派发性的东西，更像是插件模型Bryan Batchelder ，我为USB Security Key Fobs做过。

In Harald's .NET configurator, the abstract class you derive from to create a "Harald plugin" is very clean and includes new features like OnKeyHold and OnKeyDoublePress that the Optimus software doesn't make easy. He also, of course, uses BCL types like Bitmap over HDCs.

在Harald的.NET Configurator中，您从中创建“ Harald插件”的抽象类非常干净，并且包含了诸如OnKeyHold和OnKeyDoublePress之类的新功能，而Optimus软件并不容易。当然，他还使用BCL类型，例如基于HDC的位图。

 public abstract class OptimusMiniPlugin
{
    protected OptimusMiniPlugin();
    public abstract void Initialize();
    public virtual void OnKeyDoublePress();
    public virtual void OnKeyDown();
    public virtual void OnKeyHold();
    public virtual void OnKeyPress();
    public virtual void OnKeyRelease();
    public virtual void OnKeyUp();
    public abstract void Repaint();
    public void RequestNextUpdate(TimeSpan interval);
    public abstract void Terminate();
    public abstract void Update();
    public void UpdateImage(Bitmap image);
}

I'm excited to see the possibilities for this little device. Perhaps between my stuff and Haralds (and someone elses?) we can get a Windows Vista Side Show driver working for this thing...probably time for YAGCP (Yet Another Google Code Project). For now, here's what I've got. I'll do a Coding4Fun article on this in much more detail this weekend perhaps, for now, it's just scribbles and it works on my system. ;)

我很高兴看到这种小型设备的可能性。也许在我和Haralds(还有其他人？)之间，我们可以得到Windows Vista Side Show驱动程序来工作，这可能是YAGCP(另一个Google代码项目)的时间。现在，这就是我所拥有的。我可能会在本周末对此进行更详细的Coding4Fun文章，到目前为止，这只是涂鸦，并且可以在我的系统上使用。 ;)

I wonder if the Optimus Keyboard folks care...I hope so. I'm convinced that writing managed plugins is easier than unmanaged (on Windows or in Mono). Is this even worth debating?

我想知道擎天柱键盘的人是否在乎...我希望如此。我坚信(在Windows或Mono中)编写托管插件要比非托管插件容易。这甚至值得辩论吗？