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?

Nightfox

On 4/4/2011 7:04 PM, Nightfox wrote:

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?

Silly question, why not just do a winforms, or xaml project in C#? can still 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.

--
Michael J. Ryan - http://tracker1.info/

---
■ Synchronet ■ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.com

Re: Re: Visual Studio 2010 MFC dialog designer
By: Tracker1 to Nightfox on Sun Apr 17 2011 02:41:21

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.

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. :)

Nightfox

On 4/17/2011 10:40 AM, Nightfox wrote:

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.

Not sure... honestly, most of the stuff I do is either service or web based... no native gui stuff... anything with a GUI I've done for work was mandated VB.

Also, if you have to modify an older existing project, it would be good to know
how to bring up the dialog designer.

I know for the web stuff, there's tabs/buttons at the bottom for design vs. code view.

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?

It depends... there's a few instances where it's easier to make a wrapper that exposes a simpler API for C# to consume. P/Invoke can range from very simple, to complex.. You don't get to just import a header file, so making sure your types line up for more complex stuff is a bit of a pain sometimes.

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.

Most of my day to day dev is either in some backend services, or in a web based UI... some Flex/Flash as well.

--
Michael J. Ryan - http://tracker1.info/

---
■ Synchronet ■ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.com

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). Nightfox

On 4/19/2011 1:23 PM, Nightfox wrote:

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).

Winforms woeks okay in mono, but looks more alien than gtk# tends to, and most gfx extensions are native for windows...

Mainly different libraries are about providing a native look/feel... following an MVC/MVVM pattern helps though... also, winforms, and gtk# work well cross platform... there have been efforts to expose wxWidgets in a .Net binding, but none have really panned out, would probably be worth looking into.

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.

--
Michael J. Ryan - http://tracker1.info/

---
■ Synchronet ■ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.com

Re: Re: Visual Studio 2010 MFC dialog designer
By: Tracker1 to Nightfox on Thu Apr 21 2011 21:37:07

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.

Nightfox

On 4/22/2011 9:01 AM, Nightfox wrote:

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, easier 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.

--
Michael J. Ryan - http://tracker1.info/

---
■ Synchronet ■ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.com

Re: Re: Visual Studio 2010 MFC dialog designer
By: Tracker1 to Nightfox on Fri Apr 22 2011 17:41:43

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. :)

Nightfox

On 4/22/2011 7:40 PM, Nightfox wrote:

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.).

Well, if it's multi-user, and stored on a database, or other server data store, a web-app makes sense, easier to keep updated/deployed, especially the more people that need access. I've worked on more widely used intranet applications than public-facing stuff though.

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. :)

I was actually meaning ASP.Net (WebForms or MVC)... as configuring mono under Apache, nginx etc is a bit of a pain... desktop apps are far easier, as long as they're tested for the environment (Linux, OSX over Windows).

--
Michael J. Ryan - http://tracker1.info/

---
■ Synchronet ■ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.com