UI om bestaande C++ code heen maken

[ikt]

Hallo iedereen,

Hier ligt een hoopje C++ code dat iets doet met Xinput, DirectInput en meer Windows-specifieke API calls. Het heeft geen andere dependencies: ik heb een simpele console-applicatie gemaakt die mijn klasses ook gebruiken. Mijn controller en wiel werken in de console-applicatie net zo goed als in de game waar de code origineel voor dient.

Om deze code moet een UI heen, om op gebruiksvriendelijke wijze apparaten en controls te kunnen mappen. Buiten C#/Windows Forms heb ik 0 ervaring met UIs, dus ik loop hier vast. Welke UI-frameworks wordt algemeen gebruikt voor C++ zaken en wordt aangeraden?

Mijn enige eis is dat ik mijn klasses niet hoef te herschrijven en dat de applicatie die eruit voortvloeit volledig stand-alone is (en uiteraard op Windows draait).

De volgende dingen heb ik geprobeerd:

• Qt (5.7) - Het lukt me niet om een standalone Qt applicatie te maken, de guides voor Windows om een statische Qt te maken zijn vaag (of ik kan het niet vinden). Tevens crasht de applicatie al bij debuggen/runnen wanneer ik simpelweg de klasses toe voeg, nog niet eens een #include er van of dat ik een type gebruik...
• C++/CLI - Na wat aangeklungeld te hebben met mijn klasses compilerend te krijgen heb ik het opgegeven. Managed C++ code? Uit wat ik verder heb gelezen is dat ik wrappers om mijn functies moet schrijven, maar het precieze hoe en wat voor klasses zijn me toch wat raar.
• C++ DLL gebruiken in een C# Windows Forms applicatie - Hier moet ik ook wrapper code schrijven?

Hierna heb ik het opgegeven. Voor mijn console-applicatie gebruik ik maar 2 klasses die onderwater nog 6 andere (zelf geschreven)klasses gebruiken.

Ik ben op zich best bereid wrappers te maken, maar het moet niet zo worden dat ik 8 klasses opnieuw design. Door nieuwe ideeën verandert er nog wel eens wat aan de code, dus zo'n wrapper zou erg snel opnieuw geschreven moeten worden als ik alles op dezelfde code wil laten werken. Wat zou ik hier het beste kunnen doen, met het oog op zo min mogelijk pijn bij veranderingen aan de code?

De broncode is overigens op GitHub, maar schenk er maar niet te veel aandacht aan - ik vind het een wonder dat het werkt

[Ventieldopje]

Zoek eens op (C++) DLL in C# te gebruiken, dat komt wel vaker voor Of dat in jouw geval ook werkt durf ik niet te zeggen (geen tijd om heel je code door te spitten) maar dat lijkt mij een mogelijkheid iig. Je bent dan vrij om te kiezen of je het in WPF of WindowsForms doet.

Je kan er ook nog voor kiezen om C++ met MFC te gebruiken om je UI te maken.

offtopic:
Als je een console applicatie hebt kun je stiekem ook gewoon die afvuren vanuit je GUI applicatie, dan schrijf je letterlijk de GUI als wrapper. Dan ben je geheel vrij om wat dan ook voor taal te gebruiken.

[ Voor 23% gewijzigd door Ventieldopje op 05-12-2016 16:06 ]

[Radiant]

Je zou, als dat voor jou makkelijker/comfortabeler is, ook kunnen overwegen om de C++-applicatie een interface te geven om die instellingen te doen via een of andere IPC-constructie en je GUI-applicatie (die je dan in C# kan maken als jij dat makkelijk vindt) daar tegenaan laten praten.

[Killah_Priest]

Dit zijn toch juist de gevallen waarvoor je normaal gesproken P/Invoke (.NET) kunt gebruiken?

[ Voor 7% gewijzigd door Killah_Priest op 05-12-2016 16:12 ]

[Casablanca]

ik heb hier ook mee zitten aanklooien, voor CLI heb ik dit een keer als antwoord gekregen:

Essentially an operating system's windowing system exposes some API calls that you can perform to do jobs like create a window, or put a button on the window. Basically you get a suite of header files and you can call functions in those imported libraries, just like you'd do with stdlib and printf.

Each operating system comes with it's own GUI toolkit, suite of header files, and API calls, and their own way of doing things. There are also cross platform toolkits like gtk, qt, and wx widgets that help you build programs that work anywhere. They achieve this by having the same API calls on each platform, but a different implementation for those API functions that call down to the native OS API calls.

One thing they'll all have in common, which will be different from a CLI program, is something called an event loop. The basic idea there is somewhat complicated, and difficult to compress, but in essence it means that not a hell of a lot is going in in your main class/main function, except:

check the event queue if there's any new events
if there is, dispatch those events to appropriate handlers
when you're done, yield control back to the operating system (usually with some kind of special "sleep" or "select" or "yield" function call)
then the yield function will return when the operating system is done, and you have another go around the loop.
There are plenty of resources about event based programming. If you have any experience with javascript, it's the same basic idea, except that you, the scripter have no access or control over the event loop itself, or what events there are, your only job is to write and register handlers.

edit: Oh also, I forgot to mention that GUI programming is incredibly complicated and difficult, in general. If you have the option, it's actually much easier to just integrate an embedded webserver into your program and have an html/web based interface. The one exception that I've encountered is Apple's cocoa+xcode+interface builder + tutorials that make it easily the most approachable environment for people new to GUI programming that I've seen.

[farlane]

....it's actually much easier to just integrate an embedded webserver into your program and have an html/web based interface....

Wright. Eyes of the beholder en dat soort dingen...

[Casablanca]

en inderdaad moet je dat even overslaan......

farlane schreef op maandag 5 december 2016 @ 16:56:
[...]

Wright. Eyes of the beholder en dat soort dingen...

[ikt]

Ik zal eens meer kijken naar het DLL gebeuren, dat lijkt me het meest te liggen in wat ik al weet.

[.oisyn]

Maak een C++/CLI interface om je library zodat je dat heel gemakkelijk vanuit .Net aan kunt roepen. Van P/Invoke wordt je over het algemeen niet zo vrolijk, zeker niet als je te maken hebt met C++ classes.