Windows平台上最适合支票/支票打印的语言
我需要创建一个可以打印支票（填写详细信息）的简单模块/可执行文件。需要从 Windows（xp 或更高版本）上的现有 Oracle 9i DB 重试详细信息，
显然，我需要定义像素格式以填充详细信息（名称、金额等）。
主要的限制是客户端需要/强烈喜欢可执行文件，而不是解释或使用虚拟机的代码。这使得安装极其简单。这个要求确实无法改变。
现在的问题是，我该怎么做。 （.NET、java 和 python 是不可能的，除非有办法绕过 VM）
我从未使用过 MFC 或其他本机 Windows API。我对GDI也不熟悉。
我还有其他选择吗？有什么语言可以抽象出复杂性并可以打包成 x86 二进制文件吗？
另外，如果没有，那么任何有关 GDI 的代码帮助将不胜感激。
I need to create a simple module/executable that can print checks (fill out the details). The details need to be retried from an existing Oracle 9i DB on the Windows(xp or later)
Obviously, I shall need to define the pixel format as to where the details (Name, amount, etc) are to be filled.
The major constraint is that the client needs / strongly prefers a executable , not code that is either interpreted or uses a VM. This is so that installation is extremely simple. This requirement really cannot be changed.
Now, the question is, how do I do it.
(.NET, java and python are out of the question, unless there is a way around the VMs)
I have never worked with MFC or other native windows APIs. I am also unfamiliar with GDI.
Do I have any other option? Any language that can abstract the complexities and can be packed into a x86 binary?
Also, if not then any code help with GDI would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最明显的可能性可能是 C、C++ 和 Delphi。还有其他一些，例如 Ada（例如 Gnat），但我立即认为没有太多理由支持它们（特别是对于这么小的工作）。
至少按照我写的方式，语言几乎是无关紧要的。我让它几乎完全由一个外部配置文件运行，该文件给出了每个字段的名称以及应该打印的位置。我可能会使用诸如 MM_LOMETRIC 映射模式之类的东西，因此 Windows 将处理大部分到真实世界坐标的转换（并在配置文件中使用十分之一毫米，因此您可以使用坐标而无需任何转换）。
也许其中更困难的部分是数据库连接。有各种库可以帮助解决这个问题，所以这不会非常困难，但它仍然不像绘图部分那么简单。
The most obvious possibilities would probably be C, C++, and Delphi. There are a few others such as Ada (e.g., Gnat), but offhand I don't see a lot of reason to favor them (especially for a job this small).
At least the way I'd write this, the language would be almost irrelevant. I'd have it run almost entirely by an external configuration file that gave the name of each field, and the location where it should be printed. I'd probably use something like MM_LOMETRIC mapping mode, so Windows will handle most of the translation to real-world coordinates (and use tenths of a millimeter in the configuration file, so you can use the coordinates without any translation).
Probably the more difficult part of this would/will be the database connectivity. There are various libraries around to help out with that, so this won't be terribly difficult, but it's still not (quite) as trivial as the drawing part.