467,921 Members | 1,328 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,921 developers. It's quick & easy.

GUI for Decision Support System

N4M
Dear,
I am going to build a DSS for hospital scheduling. I have some
knowledge of standard C++, but I am novice to Windows programming and
GUI development. Please tell me:
1- Should I separate backend for schedulign algorithms (prbably will
be in C++) and GUI (?).
2- Should I start learning MFC or switch to C# with Window Forms?
Which option is more effective in terms of learning curve, development
time and future compatibility.
3-Your recommended references to support your answer?
Thanks a lot.
N4M.
Jul 22 '05 #1
  • viewed: 2581
Share:
3 Replies
I think the only answer you will get from people on this group
is that your question should be asked on GUI specific groups.
Your question seems to be Off Topic here.

Greets

--

Mateusz £oskot
mateusz at loskot dot net
Jul 22 '05 #2
N4M wrote:
I am going to build a DSS for hospital scheduling. I have some
knowledge of standard C++, but I am novice to Windows programming and
GUI development. Please tell me : 1- Should I separate backend for schedulign algorithms (prbably will
be in C++) and GUI (?).
What language do you know best?

You should separate the back end by writing unit tests and acceptance tests
that do everything to the backend that a user could do.
2- Should I start learning MFC or switch to C# with Window Forms?
Which option is more effective in terms of learning curve, development
time and future compatibility.


I can code WTL faster and more robust than anyone proficient with C# and
Windows Forms can. I could probably muddle along in MFC. But MFC is never a
viable system, and today is generally discredited. For example, Microsoft's
main VC++ editor, MSDev, used it, and they switched to DevEnv, which I
suspect uses something else. MFC speciallizes in "vendor lock-in", so the
effect apparently bit the vendor itself!

I would use Ruby for the back-end and Ruby/Fox or Ruby/Tk for the front end.

(Why do I post to news:comp.lang.c++ ? Because I like Ruby so much! ;)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces
Jul 22 '05 #3
N4M
"Phlip" <ph*******@yahoo.com> wrote in message news:<OD**************@newssvr16.news.prodigy.com> ...
N4M wrote:
I am going to build a DSS for hospital scheduling. I have some
knowledge of standard C++, but I am novice to Windows programming and
GUI development. Please tell me

:
1- Should I separate backend for schedulign algorithms (prbably will
be in C++) and GUI (?).


What language do you know best?

You should separate the back end by writing unit tests and acceptance tests
that do everything to the backend that a user could do.
2- Should I start learning MFC or switch to C# with Window Forms?
Which option is more effective in terms of learning curve, development
time and future compatibility.


I can code WTL faster and more robust than anyone proficient with C# and
Windows Forms can. I could probably muddle along in MFC. But MFC is never a
viable system, and today is generally discredited. For example, Microsoft's
main VC++ editor, MSDev, used it, and they switched to DevEnv, which I
suspect uses something else. MFC speciallizes in "vendor lock-in", so the
effect apparently bit the vendor itself!

I would use Ruby for the back-end and Ruby/Fox or Ruby/Tk for the front end.

(Why do I post to news:comp.lang.c++ ? Because I like Ruby so much! ;)


Thanks for your suggestion. I will write the back-end entirely in C++.
For the front-end, maybe C# is a good thing to learn (I've heard too
many people complaining of MFC, and other toolkit might be troublesome
for commercial packages?)
Jul 22 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

99 posts views Thread by Paul McGuire | last post: by
7 posts views Thread by Chinook | last post: by
7 posts views Thread by Terry Olsen | last post: by
14 posts views Thread by Mikee Freedom | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.