I started a C++ project with Visual Studio 2010. It's a dialog-based GUI application using MFC. It had the dialog GUI designer when I first started the
project, but now the GUI designer is not showing, and I haven't found how to bring it up again.. How do you bring up the dialog designer in VS2010?
I started a C++ project with Visual Studio 2010. It's a dialog-based GUI application using MFC. It had the dialog GUI designer when I first starte project, but now the GUI designer is not showing, and I haven't found how bring it up again.. How do you bring up the dialog designer in VS2010?
Silly question, why not just do a winforms, or xaml project in C#? can stil do anything that needs deeper access in C++, though C# can connect to C interfaces pretty easily (P/Invoke). Would be far easier to setup and maintain than an MFC app.
Silly question, why not just do a winforms, or xaml project in C#? can stil >> do anything that needs deeper access in C++, though C# can connect to C
interfaces pretty easily (P/Invoke). Would be far easier to setup and
maintain than an MFC app.
I agree, and I like C#, although I'm still more familiar with C++ and just wanted to get something done quick& dirty. I'd still like to know how to get
the dialog designer up.. seems weird that it came up when I first created the
project but now isn't appearing.
Also, if you have to modify an older existing project, it would be good to know
how to bring up the dialog designer.
I haven't used P/Invoke in C#, but recently I've come across it at work in looking up ways to interact with C++/C code from C# (most of the code there is
C++, but it seems like they may want to do some C# stuff eventually). Normally
I'd think of doing a managed C++ wrapper to interface with C/C++ code from .NET
- Is P/Invoke any better/worse?
As for a GUI, I've started reading about WCF, and it sounds fairly interesting.. It's something totally re-designed and is based on DirectX and lets you embed multimedia stuff (images, movies, etc.) into your GUI a lot more
easily than earlier frameworks. It sounds exciting.. I'm just disappointed that it's a Windows-only API. I like APIs that easily let you develop multi-platform apps.. It's nice to see your app easily compile for Windows, Linux, OS X, and other OSes you might want it to run on. :)
WPF would be GUI (XAML)... WCF is for communications between service layer boundaries. For cross-platform C#, would look into GTK# for GUI applications.
There's also Cocoa# if you want a native OSX UI, or can do GTK#. See MonoDevelop for example.
WPF would be GUI (XAML)... WCF is for communications between service layer >> boundaries. For cross-platform C#, would look into GTK# for GUI
applications.
There's also Cocoa# if you want a native OSX UI, or can do GTK#. See
MonoDevelop for example.
That's right, I get WPF and WCF confused sometimes.. As for a cross-platform GUI with C#, I guess I assumed WinForms was part of the standard library in .NET and thus would be available on other platforms too (i.e. with MonoDevelop). The idea of having to use a different GUI library for a different platform with C# seems strange.. And ideally, I'd think it should always look like a native app (similar to the wxWidgets way of doing things).
I'd probably just use Air or a web interface myself... though I just tend to lean that way, not too many applications need to be desktop bound imho.
I'd probably just use Air or a web interface myself... though I just tend to >> lean that way, not too many applications need to be desktop bound imho.
I usually tend to lean toward a desktop interface, feeling like not too many apps need to be web-based. :) It feels like web apps are harder to develop due to the nature of HTTP being a stateless protocol, etc.. And you also have
to worry about differences in web browser implementations and how they follow standards, etc. And web-based languages like PHP, etc. are harder to develop -
AFAIK, there isn't an good way to step through the code line-by-line as it executes. I feel like desktop apps are just faster than web apps, too.
There's always ASP.Net MVC (line-by-line debugging, razer view engine, easie JS endpoints)... jQuery handles a lot of the DOM inconsistencies, and the UI work isn't too bad.
Deploying on something that isn't windows (Mono) is a bit of a b*tch though.
There's always ASP.Net MVC (line-by-line debugging, razer view engine, easie >> JS endpoints)... jQuery handles a lot of the DOM inconsistencies, and the UI >> work isn't too bad.
I suppose that's true.. But then, why develop something as a web app when it can be a desktop app? I guess the reasons aren't so clear to me.. Plus, I tend not to like the fact that web-based apps often feel a little slower because of network latency, and also I don't like the idea of my data being stored on someone else's server (and not knowing what they might do with my data, or that my data is properly protected in case their servers crash, etc.).
Deploying on something that isn't windows (Mono) is a bit of a b*tch though.
That seems a bit ironic, considering that .NET was designed to provide a platform-independent virtual machine, similar to Java. :)
| Sysop: | Eric Oulashin |
|---|---|
| Location: | Beaverton, Oregon, USA |
| Users: | 99 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 00:43:23 |
| Calls: | 3,538 |
| Calls today: | 5 |
| Files: | 8,461 |
| Messages: | 337,339 |