edit
alright, I guess C is painful in nature--Just, this part, is particularly painful.
Also, there isn't a real reason I'm only writing in C, other than, that's the language I want to write in, and be proficient in, for now. I know moving from C to C++ is bad, but whatever.
好吧,我猜C在本质上是痛苦的 - 只是,这部分,特别痛苦。另外,没有一个真正的原因我只用C语言写作,除了,这是我想写的语言,并且现在精通。我知道从C转向C ++很糟糕,但无论如何。
And does anyone know a solution, to my problem with making more than one window in a program?
有没有人知道一个解决方案,我在一个程序中创建多个窗口的问题?
Well, I was interfacing a C DLL with a VB6 front-end, but -- trying to pass strings back and forth got ugly, and it seemed like every time I added a new function, everything else would break. So, I thought, Why would I put myself through all this pain just to interface with a language that isn't even supported anymore? Why not just put that pain to better use and learn to build a front-end in C?
好吧,我正在连接一个C DLL和一个VB6前端,但是 - 尝试来回传递字符串变得很难看,似乎每当我添加一个新函数时,其他一切都会破坏。所以,我想,为什么我只是为了与一种甚至不再支持的语言接口而让自己完成所有这些痛苦?为什么不把这种痛苦用于更好地利用并学习在C中构建前端?
Well I started, but I have to ask: is there an easy way to do this? The huge switch statement that is WndProc is hurting my eyes, and going against everything I learned about clean code (much like the 12 parameter CreateWindowEx(), or the 14 parameter CreateFont()).
好吧,我开始了,但我不得不问:有一个简单的方法吗? WndProc这个巨大的开关语句伤害了我的眼睛,并且反对我学习干净代码的一切(很像12参数CreateWindowEx()或14参数CreateFont())。
I realize I could refactor all this -- to an extent -- and if I was using C++ I could put windows and their components into classes and access them in a more natural way I suppose...
我意识到我可以在某种程度上重构所有这些 - 如果我使用C ++,我可以将窗口及其组件放入类中,并以更自然的方式访问它们,我想...
Anyways, I managed to construct a big form titled "Main Window!", with a "Popup Message!" button, which works alright -- and it wasn't complicated at all. Then there's a "Change that text!" button which changes the text in an edit control. For this to be possible, the WndProc has to know about the edit control while it's receiving a WM_COMMAND message from the button. I can't pass the hWnd for the edit control into it, since I'm not the one calling it and you can't just add arguments to WndProc. So I had to put the edit control in global scope.
无论如何,我设法建立了一个名为“主窗口!”的大表格,带有“弹出消息!”按钮,工作正常 - 并没有复杂。然后是“改变那个文字!”用于更改编辑控件中文本的按钮。为了实现这一点,WndProc在从按钮接收WM_COMMAND消息时必须知道编辑控件。我不能将编辑控件的hWnd传递给它,因为我不是那个调用它的人,你不能只是向WndProc添加参数。所以我不得不将编辑控件放在全局范围内。
I wanted to change the font of the buttons to 13pt Tahoma -- easy, right? Of course -- but I couldn't get any farther than the WM_PARENTNOTIFY message... After some careful reading of MSDN, I discovered that some information is in the high word of wParam, and some in the low word. So, I had to write this: if(wParam==(WM_CREATE | (POPUP_COMMAND<<16))){
我想将按钮的字体改为13pt Tahoma - 简单,对吧?当然 - 但是我无法获得比WM_PARENTNOTIFY消息更远的信息......经过仔细阅读MSDN后,我发现有些信息在wParam的高位字中,有些信息在低位字中。所以,我必须写这个:if(wParam ==(WM_CREATE |(POPUP_COMMAND << 16))){
Making the controls global? huge switch statements? 12 and 14 parameter function calls? Bit shifts for simple notifications? I still can't even figure out how to make more that one window (window window, not control window) appear--this is painful...
使控件全球化?巨大的转换声明? 12和14参数函数调用?简单通知的位移?我仍然无法弄清楚如何使一个窗口(窗口窗口,而不是控制窗口)出现更多 - 这很痛苦......
Please tell me there's a better way!
请告诉我有更好的方法!
How do I make more than one window by the way? If I just register two classes, or CreateWindowEx on the same class twice (for two handles), only the first will appear. I tried playing with the dwStyle parameter a little, but to no avail. Anyone?
顺便说一下,如何制作多个窗口?如果我只在同一个类上注册两个类或CreateWindowEx两次(对于两个句柄),则只会出现第一个类。我尝试了一点dwStyle参数,但无济于事。任何人?
9 个解决方案
#1
Win32 + C is a very low-level approach, which has its advantages and disadvantages. That said, there are ways to make things easier.
Win32 + C是一种非常低级的方法,它有其优点和缺点。也就是说,有办法让事情变得更容易。
First, regarding bit-shifts, there are several macros to work with WPARAMs and LPARAMs. You probably shouldn't be writing bit-shifts, in fact, because the size of WPARAM and LPARAM has changed over the years, and you might be creating a future bug.
首先,关于位移,有几个宏可用于WPARAM和LPARAM。事实上,你可能不应该写位移,因为多年来WPARAM和LPARAM的大小发生了变化,你可能会创建一个未来的bug。
Secondly, regarding the giant switch statement in your WindowProc function, while that will be there, there's a way to make it a bit more manageable. #include <windowsx.h> to get a whole bunch of useful macros, most notably HANDLE_MSG. Instead of needing to write
其次,关于WindowProc函数中的巨型switch语句,虽然它会存在,但有一种方法可以让它更易于管理。 #include
LRESULT CALLBACK MyWindowProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) {
switch(Message) {
case WM_COMMAND:
...
}
}
You can instead write:
你可以写:
void MyOnCommand(HWND hwnd, int controlID, HWND hwndCtl, UINT codeNotify);
LRESULT CALLBACK MyWindowProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) {
switch(Message) {
HANDLE_MSG(hwnd, WM_COMMAND, MyOnCommand);
}
}
and the macro automatically casts and separates all the different parameters for that message type into the appropriately named & typed variables. Browse windowsx.h to see the messages that are handled, and the function prototypes it requires. Not all the different messages are handled, but quite a few are.
并且宏自动将该消息类型的所有不同参数转换并分离为适当命名的&typed变量。浏览windowsx.h以查看所处理的消息以及它所需的函数原型。并非所有不同的消息都被处理,但有不少消息。
As for having multiple windows at once, there shouldn't be anything stopping you from calling CreateWindow or its relatives multiple times. While you only have one HINSTANCE (given to you in your WinMain), you can have as many HWNDs as you want.
至于同时拥有多个窗口,不应该有任何阻止你多次调用CreateWindow或其亲属的东西。虽然您只有一个HINSTANCE(在WinMain中为您提供),但您可以拥有任意数量的HWND。
You may find Raymond Chen's scratch program useful, as it should give you a decent skeleton to start from. You might also consider making your application use a dialog box instead of just a window; you get a bunch of stuff for free, and you can use a resource editor to design the window and all its controls. Visual C++ Standard and above include a resource editor, and there are also several free ones: XN Resource Editor seems to be a popular open-source editor, and I'm sure you can find more on Google. All of these produce a resource script, and you should have a resource compiler in your toolchain: rc.exe for Visual Studio (including the Express Editions, or available as part of the SDK), or windres as part of the GNU BinUtils in cygwin or mingw.
您可能会发现Raymond Chen的临时程序非常有用,因为它应该为您提供一个合适的骨架。您还可以考虑使应用程序使用对话框而不仅仅是窗口;你可以免费获得一堆东西,你可以使用资源编辑器来设计窗口及其所有控件。 Visual C ++ Standard及以上版本包括一个资源编辑器,还有一些免费版本:XN Resource Editor似乎是一个流行的开源编辑器,我相信你可以在Google上找到更多。所有这些都产生了一个资源脚本,你应该在你的工具链中有一个资源编译器:用于Visual Studio的rc.exe(包括Express Editions,或作为SDK的一部分提供),或者作为cygwin中GNU BinUtils的一部分的windres或者mingw。
#2
Speaking as an ex-instructor in C Windows programming, I can safely say that there is no easy way to build a GUI using C - the language is not well suited to the task. Almost anything else would be a better choice - my own favourite for GUI development is Delphi.
作为C Windows编程的前任讲师,我可以肯定地说,使用C构建GUI没有简单的方法 - 语言不适合这项任务。几乎任何其他东西都是更好的选择 - 我自己最喜欢的GUI开发是Delphi。
#3
I'll toss in my traditional outside-the-box suggestion: Add Lua to your application, and build the GUI with a combination of Lua and a suitable toolkit module. One good choice is IUP, and another is wxWidgets. Both have decent quality Lua bindings. Even better, Lua itself along with both wxLua and IUP can be had in a single installation along with a bunch of other useful Lua modules from the Lua for Windows project.
我将抛弃我传统的开箱即用建议:将Lua添加到您的应用程序中,并使用Lua和合适的工具包模块组合构建GUI。一个很好的选择是IUP,另一个是wxWidgets。两者都具有相当优质的Lua绑定。更好的是,Lua本身以及wxLua和IUP都可以在一个安装中与Lua for Windows项目中的一堆其他有用的Lua模块一起使用。
Lua is easy to integrate with C code, since it was designed for that purpose from the outset.
Lua很容易与C代码集成,因为它从一开始就是为此目的而设计的。
It is also easy to use Lua as the glue that hold the application together, with core functionality implemented in C or as interfaces to native API calls.
使用Lua作为将应用程序保持在一起的粘合剂也很容易,其核心功能在C中实现,或者作为本机API调用的接口实现。
Lua is also supported by SWIG in case you have an extensive library to adapt.
如果您有适合的广泛库,SWA也会支持Lua。
Of course, you could just use either wxWidgets or IUP directly from C as they both have C callable APIs, but event-driven GUIs are often full of nit-picky little house-keeping callback functions that are easy to deal with in a scripting language.
当然,您可以直接使用来自C的wxWidgets或IUP,因为它们都具有C可调用API,但事件驱动的GUI通常充满了极易处理的小型管家回调函数,这些函数易于用脚本语言处理。
Another toolkit to consider is Tk, which is most often seen in combination with the Tcl scripting language. Tcl was also developed with embedding in a larger application in mind, although it has evolved away from that as its primary use case. Tk has been bound to a variety of other languages, including Perl.
另一个需要考虑的工具包是Tk,它最常见于Tcl脚本语言。 Tcl的开发也考虑了嵌入在更大的应用程序中,尽管它已经从它作为主要用例发展而来。 Tk已经被各种其他语言所包括,包括Perl。
#4
I've never really seen a problem writing Win32 stuff in pure C, I actually think it's a lot cleaner than the alternatives I've tried (MFC, WTL, QT and a few others). A few simple pointers:
我从来没有真正看到在纯C中编写Win32的问题,我实际上认为它比我尝试的替代品(MFC,WTL,QT和其他一些)更清洁。一些简单的指针:
-
Regarding high- and low-word parameters, there's nice macros to handle that for you -- the names elude me right now though.
关于高字和低字参数,有很好的宏可以为你处理 - 虽然这些名字现在让我无法理解。
-
You can work in a rather nice object-oriented manner by allocating an "application" struct and storing its address with SetWindowLong(), that solves you problem of having global handles.
通过分配“应用程序”结构并使用SetWindowLong()存储其地址,您可以以一种相当不错的面向对象的方式工作,这解决了您具有全局句柄的问题。
-
You can create a rather simple mapping from a WM_MESSAGE -> function pointer to ease the redability of the long switch in your window processes, or just refactor it into simpler functions to get a better overview.
您可以从WM_MESSAGE - >函数指针创建一个相当简单的映射,以简化窗口进程中长开关的可重新性,或者只是将其重构为更简单的函数以获得更好的概览。
So, in all, it's possible to write nice and clean stuff, but it's hard. The same goes for every other method though, the only thing that differs are the values of "possible" and "hard" :)
所以,总而言之,可以编写漂亮而干净的东西,但这很难。对于其他所有方法都是如此,唯一不同的是“可能”和“硬”的值:)
#5
There is a better way. Use Qt. It's for C++, but C++ is better suited for GUIs, because its object oriented model fits the domain very well. Qt itself is a great library of amazing depth and breadth, well-supported and designed, licensed with LGPL and fun to use. It comes with a complete GUI designer that can help you build dialogs in a graphical manner very quickly.
有一个更好的办法。使用Qt。它适用于C ++,但C ++更适合GUI,因为它的面向对象模型非常适合这个领域。 Qt本身是一个令人惊叹的深度和广度,良好支持和设计,LGPL许可和使用乐趣的伟大的库。它配备了完整的GUI设计器,可以帮助您以图形方式快速构建对话框。
If you insist on C and native Win32, there's also a way. Buy Petzold's Programming Windows book - it's very good. After reading the first few chapters you'll be able to build interesting GUIs in C relatively easily. Much more code and effort will be required than with Qt, but the positive side is that you'll get tiny and fast executables without external dependencies.
如果你坚持使用C和本机Win32,那么还有一种方法。购买Petzold的编程Windows书籍 - 非常好。阅读前几章后,您将能够相对轻松地在C中构建有趣的GUI。与Qt相比,需要更多的代码和工作量,但积极的一面是,您将获得没有外部依赖性的小而快的可执行文件。
#6
GUIs are ideally handled by more abstract languages than C, otherwise there's lots of redundant boilerplate code, in this sense I'd advise you to consider embedding a scripting language interpreter into your C application, so that the GUI is largely driven by scripts, while the core of your application is coded in C.
GUI理想地由比C更抽象的语言处理,否则有很多冗余的样板代码,在这个意义上我建议你考虑将脚本语言解释器嵌入到你的C应用程序中,这样GUI很大程度上是由脚本驱动的,而您的应用程序的核心用C编码。
This would also have the advantage of making your application more configurable and more flexible without necessarily requiring recompilation.
这样做的另一个好处是可以使您的应用程序更具可配置性和灵活性,而无需重新编译。
You will want to look into lightweight scripting engines that are written in ANSI C and that provide bindings to GUI libraries such as QT, GTK, wxWindows etc.
您将需要研究用ANSI C编写的轻量级脚本引擎,它们提供对GUI库的绑定,如QT,GTK,wxWindows等。
You might want to check out Lua or nasal both of which are fairly lightweight and do provide bindings for GUI libs.
您可能想要检查Lua或nasal,它们都相当轻量级并且为GUI库提供绑定。
For some example uses, you might want to check out the following screenshots of two applications that feature GUIs that are largely based on nasal and its GTK bindings:
对于某些示例用途,您可能需要查看两个具有GUI的应用程序的以下屏幕截图,这些GUI主要基于nasal及其GTK绑定:
- KyCE II - Kymatica Compositional Environment
- AlgoScore
- AlgoScore
KyCE II - Kymatica成分环境
#7
If you want to do it in C, you definitely want Charles Petzold's Programming Windows.
如果你想用C语言做,你肯定想要Charles Petzold的Programming Windows。
#8
Just to give you an idea how C compares to other languages when in comes to Win UI apps: Some time ago a simple MDI application with a few windows and a few classes to visualise medical data took me 17k lines of code in C. I rewrote this in Delphi a couple of years later, and it took only 5k LOCs.
只是为了让你了解C在与Win UI应用程序相比时如何与其他语言进行比较:前段时间,一个简单的MDI应用程序带有几个窗口和几个可视化医疗数据的类,我在C中使用了17k行代码。几年之后,在德尔福,这只占用了5k个LOC。
#1
Win32 + C is a very low-level approach, which has its advantages and disadvantages. That said, there are ways to make things easier.
Win32 + C是一种非常低级的方法,它有其优点和缺点。也就是说,有办法让事情变得更容易。
First, regarding bit-shifts, there are several macros to work with WPARAMs and LPARAMs. You probably shouldn't be writing bit-shifts, in fact, because the size of WPARAM and LPARAM has changed over the years, and you might be creating a future bug.
首先,关于位移,有几个宏可用于WPARAM和LPARAM。事实上,你可能不应该写位移,因为多年来WPARAM和LPARAM的大小发生了变化,你可能会创建一个未来的bug。
Secondly, regarding the giant switch statement in your WindowProc function, while that will be there, there's a way to make it a bit more manageable. #include <windowsx.h> to get a whole bunch of useful macros, most notably HANDLE_MSG. Instead of needing to write
其次,关于WindowProc函数中的巨型switch语句,虽然它会存在,但有一种方法可以让它更易于管理。 #include
LRESULT CALLBACK MyWindowProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) {
switch(Message) {
case WM_COMMAND:
...
}
}
You can instead write:
你可以写:
void MyOnCommand(HWND hwnd, int controlID, HWND hwndCtl, UINT codeNotify);
LRESULT CALLBACK MyWindowProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) {
switch(Message) {
HANDLE_MSG(hwnd, WM_COMMAND, MyOnCommand);
}
}
and the macro automatically casts and separates all the different parameters for that message type into the appropriately named & typed variables. Browse windowsx.h to see the messages that are handled, and the function prototypes it requires. Not all the different messages are handled, but quite a few are.
并且宏自动将该消息类型的所有不同参数转换并分离为适当命名的&typed变量。浏览windowsx.h以查看所处理的消息以及它所需的函数原型。并非所有不同的消息都被处理,但有不少消息。
As for having multiple windows at once, there shouldn't be anything stopping you from calling CreateWindow or its relatives multiple times. While you only have one HINSTANCE (given to you in your WinMain), you can have as many HWNDs as you want.
至于同时拥有多个窗口,不应该有任何阻止你多次调用CreateWindow或其亲属的东西。虽然您只有一个HINSTANCE(在WinMain中为您提供),但您可以拥有任意数量的HWND。
You may find Raymond Chen's scratch program useful, as it should give you a decent skeleton to start from. You might also consider making your application use a dialog box instead of just a window; you get a bunch of stuff for free, and you can use a resource editor to design the window and all its controls. Visual C++ Standard and above include a resource editor, and there are also several free ones: XN Resource Editor seems to be a popular open-source editor, and I'm sure you can find more on Google. All of these produce a resource script, and you should have a resource compiler in your toolchain: rc.exe for Visual Studio (including the Express Editions, or available as part of the SDK), or windres as part of the GNU BinUtils in cygwin or mingw.
您可能会发现Raymond Chen的临时程序非常有用,因为它应该为您提供一个合适的骨架。您还可以考虑使应用程序使用对话框而不仅仅是窗口;你可以免费获得一堆东西,你可以使用资源编辑器来设计窗口及其所有控件。 Visual C ++ Standard及以上版本包括一个资源编辑器,还有一些免费版本:XN Resource Editor似乎是一个流行的开源编辑器,我相信你可以在Google上找到更多。所有这些都产生了一个资源脚本,你应该在你的工具链中有一个资源编译器:用于Visual Studio的rc.exe(包括Express Editions,或作为SDK的一部分提供),或者作为cygwin中GNU BinUtils的一部分的windres或者mingw。
#2
Speaking as an ex-instructor in C Windows programming, I can safely say that there is no easy way to build a GUI using C - the language is not well suited to the task. Almost anything else would be a better choice - my own favourite for GUI development is Delphi.
作为C Windows编程的前任讲师,我可以肯定地说,使用C构建GUI没有简单的方法 - 语言不适合这项任务。几乎任何其他东西都是更好的选择 - 我自己最喜欢的GUI开发是Delphi。
#3
I'll toss in my traditional outside-the-box suggestion: Add Lua to your application, and build the GUI with a combination of Lua and a suitable toolkit module. One good choice is IUP, and another is wxWidgets. Both have decent quality Lua bindings. Even better, Lua itself along with both wxLua and IUP can be had in a single installation along with a bunch of other useful Lua modules from the Lua for Windows project.
我将抛弃我传统的开箱即用建议:将Lua添加到您的应用程序中,并使用Lua和合适的工具包模块组合构建GUI。一个很好的选择是IUP,另一个是wxWidgets。两者都具有相当优质的Lua绑定。更好的是,Lua本身以及wxLua和IUP都可以在一个安装中与Lua for Windows项目中的一堆其他有用的Lua模块一起使用。
Lua is easy to integrate with C code, since it was designed for that purpose from the outset.
Lua很容易与C代码集成,因为它从一开始就是为此目的而设计的。
It is also easy to use Lua as the glue that hold the application together, with core functionality implemented in C or as interfaces to native API calls.
使用Lua作为将应用程序保持在一起的粘合剂也很容易,其核心功能在C中实现,或者作为本机API调用的接口实现。
Lua is also supported by SWIG in case you have an extensive library to adapt.
如果您有适合的广泛库,SWA也会支持Lua。
Of course, you could just use either wxWidgets or IUP directly from C as they both have C callable APIs, but event-driven GUIs are often full of nit-picky little house-keeping callback functions that are easy to deal with in a scripting language.
当然,您可以直接使用来自C的wxWidgets或IUP,因为它们都具有C可调用API,但事件驱动的GUI通常充满了极易处理的小型管家回调函数,这些函数易于用脚本语言处理。
Another toolkit to consider is Tk, which is most often seen in combination with the Tcl scripting language. Tcl was also developed with embedding in a larger application in mind, although it has evolved away from that as its primary use case. Tk has been bound to a variety of other languages, including Perl.
另一个需要考虑的工具包是Tk,它最常见于Tcl脚本语言。 Tcl的开发也考虑了嵌入在更大的应用程序中,尽管它已经从它作为主要用例发展而来。 Tk已经被各种其他语言所包括,包括Perl。
#4
I've never really seen a problem writing Win32 stuff in pure C, I actually think it's a lot cleaner than the alternatives I've tried (MFC, WTL, QT and a few others). A few simple pointers:
我从来没有真正看到在纯C中编写Win32的问题,我实际上认为它比我尝试的替代品(MFC,WTL,QT和其他一些)更清洁。一些简单的指针:
-
Regarding high- and low-word parameters, there's nice macros to handle that for you -- the names elude me right now though.
关于高字和低字参数,有很好的宏可以为你处理 - 虽然这些名字现在让我无法理解。
-
You can work in a rather nice object-oriented manner by allocating an "application" struct and storing its address with SetWindowLong(), that solves you problem of having global handles.
通过分配“应用程序”结构并使用SetWindowLong()存储其地址,您可以以一种相当不错的面向对象的方式工作,这解决了您具有全局句柄的问题。
-
You can create a rather simple mapping from a WM_MESSAGE -> function pointer to ease the redability of the long switch in your window processes, or just refactor it into simpler functions to get a better overview.
您可以从WM_MESSAGE - >函数指针创建一个相当简单的映射,以简化窗口进程中长开关的可重新性,或者只是将其重构为更简单的函数以获得更好的概览。
So, in all, it's possible to write nice and clean stuff, but it's hard. The same goes for every other method though, the only thing that differs are the values of "possible" and "hard" :)
所以,总而言之,可以编写漂亮而干净的东西,但这很难。对于其他所有方法都是如此,唯一不同的是“可能”和“硬”的值:)
#5
There is a better way. Use Qt. It's for C++, but C++ is better suited for GUIs, because its object oriented model fits the domain very well. Qt itself is a great library of amazing depth and breadth, well-supported and designed, licensed with LGPL and fun to use. It comes with a complete GUI designer that can help you build dialogs in a graphical manner very quickly.
有一个更好的办法。使用Qt。它适用于C ++,但C ++更适合GUI,因为它的面向对象模型非常适合这个领域。 Qt本身是一个令人惊叹的深度和广度,良好支持和设计,LGPL许可和使用乐趣的伟大的库。它配备了完整的GUI设计器,可以帮助您以图形方式快速构建对话框。
If you insist on C and native Win32, there's also a way. Buy Petzold's Programming Windows book - it's very good. After reading the first few chapters you'll be able to build interesting GUIs in C relatively easily. Much more code and effort will be required than with Qt, but the positive side is that you'll get tiny and fast executables without external dependencies.
如果你坚持使用C和本机Win32,那么还有一种方法。购买Petzold的编程Windows书籍 - 非常好。阅读前几章后,您将能够相对轻松地在C中构建有趣的GUI。与Qt相比,需要更多的代码和工作量,但积极的一面是,您将获得没有外部依赖性的小而快的可执行文件。
#6
GUIs are ideally handled by more abstract languages than C, otherwise there's lots of redundant boilerplate code, in this sense I'd advise you to consider embedding a scripting language interpreter into your C application, so that the GUI is largely driven by scripts, while the core of your application is coded in C.
GUI理想地由比C更抽象的语言处理,否则有很多冗余的样板代码,在这个意义上我建议你考虑将脚本语言解释器嵌入到你的C应用程序中,这样GUI很大程度上是由脚本驱动的,而您的应用程序的核心用C编码。
This would also have the advantage of making your application more configurable and more flexible without necessarily requiring recompilation.
这样做的另一个好处是可以使您的应用程序更具可配置性和灵活性,而无需重新编译。
You will want to look into lightweight scripting engines that are written in ANSI C and that provide bindings to GUI libraries such as QT, GTK, wxWindows etc.
您将需要研究用ANSI C编写的轻量级脚本引擎,它们提供对GUI库的绑定,如QT,GTK,wxWindows等。
You might want to check out Lua or nasal both of which are fairly lightweight and do provide bindings for GUI libs.
您可能想要检查Lua或nasal,它们都相当轻量级并且为GUI库提供绑定。
For some example uses, you might want to check out the following screenshots of two applications that feature GUIs that are largely based on nasal and its GTK bindings:
对于某些示例用途,您可能需要查看两个具有GUI的应用程序的以下屏幕截图,这些GUI主要基于nasal及其GTK绑定:
- KyCE II - Kymatica Compositional Environment
- AlgoScore
- AlgoScore
KyCE II - Kymatica成分环境
#7
If you want to do it in C, you definitely want Charles Petzold's Programming Windows.
如果你想用C语言做,你肯定想要Charles Petzold的Programming Windows。
#8
Just to give you an idea how C compares to other languages when in comes to Win UI apps: Some time ago a simple MDI application with a few windows and a few classes to visualise medical data took me 17k lines of code in C. I rewrote this in Delphi a couple of years later, and it took only 5k LOCs.
只是为了让你了解C在与Win UI应用程序相比时如何与其他语言进行比较:前段时间,一个简单的MDI应用程序带有几个窗口和几个可视化医疗数据的类,我在C中使用了17k行代码。几年之后,在德尔福,这只占用了5k个LOC。