|
I would not use Managed C++ to build a GUI. I would use instead C#. That said, MFC is quite powerful (nothing is really easy when talking about Windows programming).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Agree that one should not use Managed C++ for building GUI. Managed C++ is mainly for compiling legacy C++ code, where performance is not an issue. Or wrapping native C++ code as standard .NET classes.
I would choose Winforms/C# over MFC/C++.
|
|
|
|
|
Starting from what level of development skills ?
IMO, they are both equivalent, have a look at your requirements and match them to what MFC and .NET (forms) have to offer.
M.
This signature was proudly tested on animals.
|
|
|
|
|
It's also depends a lot on the UI features you want to develop. Could you elaborate a bit on that part ?
|
|
|
|
|
If you have experience in .NET, you could choose .NET because it's easier. I'd personally choose MFC, because I've been using it to build GUI for a while and I find it convenient for my purposes.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Hi expert,
I've experience in Paint, should I use it?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Why not? But, I must warn you that it might take longer than expected.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Well, could always draw in paint the code you want to write, then use OCR to convert it to text and paste it to your compiler, but I'm not so sure that it is the most efficient solution
|
|
|
|
|
I think you should use C# or VC++/CLI, Because MFC is dieing. Fewer and fewer people are using MFC.
modified on Tuesday, January 19, 2010 2:11 PM
|
|
|
|
|
CODEPC wrote: Fewer and fewer people are using MFC.
Which puts me into the fewer and fewer category, I guess.
Maya just doesn't play along well with .NET and most of our applications are written in C++, so there's no point in writing only the UI with .NET. Some may think I'm "stuck" with native language programming, but I'm doing it because I'm liking it.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
COBOL death was ruled many many years ago, before you and possibly I (!?!) were born, anyway there are still job openings for COBOL people. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I'm for one glad that COBOL is not the standard requirement for new job positions. Awful language when having tried Java or .NET.
|
|
|
|
|
Who, besides Nish, is using C++/CLI for an actual shipping program? (C++/CLI is one of the biggest pains in the ass I've ever used.)
|
|
|
|
|
There a lot of old applications that still are implemented in MFC. These will not disappear soon, but yes any new GUI applications are usually implemented either as a web-application or using Winforms/WPF.
|
|
|
|
|
If MFC is dying, why do new versions keep being released for each new version of VS [^]?
Steve
_________________
I C(++) therefore I am
|
|
|
|
|
We are changing the style of our MFC app to be the "XP Style" - mainly this was done by setting the manifest using a #pragma comment in stdafx.h.
The problem we have is that edit fields created in Dialogs using the resource editor have a blue border to them, whereas dynamically-created ones have a black border. I had planned to get around this by subclassing CEdit and overriding OnNcPaint() and OnNcCreate().
The OnNcPaint() works fine - as the mouse passes over the entryfield the border colour is changed to the blue as required. However, the field is still initially created with the black border, so I had expected to also need to override OnNcCreate():
BOOL CXPEdit::OnNcCreate(LPCREATESTRUCT lpcs)
{
CEdit::OnNcCreate(lpcs);
OnNcPaint();
return TRUE;
}
However this doesn't seem to work. I do have the "ON_WM_NCCREATE()" and the method is definitely called, it just doesn't repaint the border. I tried adding Invalidate() and UpdateWindow() to no avail.
Any ideas?
Thanks
-M.
|
|
|
|
|
May be you can consider using an owner drawn edit box.
|
|
|
|
|
Well I've managed to get around the problem as I got the dynamic edit control to draw the same by adding the ClientEdge extended style and removing the border. However, it doesn't explain the problem above still!
|
|
|
|
|
That's weird... Try calling:
pWnd->SendMessage(WM_THEMECHANGED, 0, 0);<br />
pWnd->SendMessage(WM_NCPAINT, 0, 0);<br />
after you create those edit controls dinamically
|
|
|
|
|
Hi,
Actaully my applicaiton is like small window that will get in top of the desktop screen,the Height of window is 40.
Whats my problem is if my applcaiton is running,the items in desktop is hided behind the application.
To access desktop items like MyComputer,My Documents,i have to minimize the applcaiton and im invoking tht.
Is there any way,immediately when my application is get invoked,all desktop items should display after 40 pixel.
Pls help me.
Anu
|
|
|
|
|
I don't know of any easier way -that only means i don't know about it, not that it does not exist- but you could try hooking into the control that hosts the icons on the desktop (i believe it is some derivate of the common list control) and handle WM_NCCALCSIZE[^] to change the client area of this control. Dunno if this would work or not, never tried it, but it might...
[Edit] Also, look at SystemParametersInfo[^] with SPI_GETWORKAREA and SPI_SETWORKAREA for the uiAction parameter of it, these look promising [/Edit]
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
|
using System;
using System.Collections.Generic;
using System.Text;
using System.Collections;
namespace GenericMergeSort
{
class MergeSort
{
/// <summary>
/// Sorts an array of Objects
/// IComparable - use 'CompareTo' to compare objects
/// where T : new() - need to create a new Type 'T' object inside the method
/// </summary>
/// <param name="X"></param>
public static T[] Merge_Sort<T>(T[] X) where T : IComparable, new()
{
int n = X.Length;
X = MegrgeSort_Internal(X, n);
return X;
}
/// <summary>
/// Internal method for sorting
/// </summary>
/// <param name="X"></param>
/// <param name="n"></param>
private static T[] MegrgeSort_Internal<T>(T[] X, int n) where T : IComparable, new()
{
// Define 2 aid Sub-Arrays
T[] A = new T[(n / 2) + 2];
T[] B = new T[(n / 2) + 2];
// Initialize the 2 Sub-Arrays with an infinite 'sorting parameter'
// Therefor, You must include a default ctor in your class
// which will initialize an infinite value - To the sorting parameter
// using 'where T : new()' here
for (int i = 0; i < A.Length; i++)
{
A[i] = new T(); ;
B[i] = new T();
}
// Recursive Stop-Condition, Sorting a Basic Array (Size 2)
if (n == 2)
{
int CompareValue = X[0].CompareTo(X[1]);
if (CompareValue > 0)
{
T tempT = X[0];
X[0] = X[1];
X[1] = tempT;
}
}
else
{
// The Sub-Arrays Size is Large than 2
if (n > 2)
{
int m = n / 2;
// Initialize the 2 Sub-Arrays (The first relevant values)
for (int i = 0; i < m; i = i + 1)
{
A[i] = X[i];
}
for (int j = m; j < n; j++)
{
B[j - m] = X[j];
}
// 2 Recursive Calling, Sorting Sub-Arrays
A = MegrgeSort_Internal(A, m);
B = MegrgeSort_Internal(B, n - m);
// Merging the Sorted Sub-Arrays into the main Array
int p = 0;
int q = 0;
for (int k = 0; k < n; k++)
{
{
int CompareValure = A[p].CompareTo(B[q]);
if (CompareValure == 0 ||
CompareValure == -1)
{
X[k] = A[p];
p = p + 1;
}
else
{
X[k] = B[q];
q = q + 1;
}
}
}
} // if
} // else
return X;
} // MegrgeSort_Internal
}
}
|
|
|
|
|
Few notes:
- The subject should be written using English language.
- Your code is not properly formatted.
- The code looks managed one, i.e. you have missed the right forum.
- There is no question at all.
BTW: Welcome at CodeProject.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
That's nice.
What was the question?
edit: Ninja'd! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
