Fog Creek Software
Discussion Board




Swing to MFC

My company has several Swing applications we want to port to MFC. The reason is something among the lines of memory usage and sluggishness. Several users have also complained about pauses... ;)
Now, our team has 2 years of Swing development. How hard will it be to go from Swing to MFC?

Hooked on a Feeling
Tuesday, June 22, 2004

hahahahahahahahaaa

muppet is now from madebymonkeys.net
Tuesday, June 22, 2004

How about just fixing your Swing application before rewriting in MFC, which will take you almost forever if you haven't done MFC before.

I write large client-side Swing applications. Done properly, you can get a responsive UI. I do it, and so do others. Maybe you should go find some Java project with a speedy UI and hire somebody?

Fred
Tuesday, June 22, 2004

Whatever you do, please, please, please put scroll-wheel support everywhere there's a scrollbar.

Too many Java developers forget to do this.

Wayne
Tuesday, June 22, 2004

Easy. Just advertise for coders with MFC skills. Don't forget to specify which version you want, and accept nothing less than three years experience.

Do not pay any more than $50,000. Code monkeys have been paid too much for too long. Be strict with deadlines. Coders have had an easy life. Four weeks should be ample for any project. Hell, I can write a report in two days.

CEO On The Take
Tuesday, June 22, 2004

In the current version of Swing scroll wheel support is either default or set with a flag so that it no problem.  As for the sluggishness, try putting time consuming tasks in a separate thread and use invokeLater when it returns.  Works wonders.  As for the memory problem you may have a problem using the default models instead of your own in large MVC situations.  Of course the big memory footprint comes with the territory to spome extent with Java.

As for porting to MFC my guess is that if you have a complex app and have teken advantage of MVC in your design it is going to be a huge pain.  If not it should be fairly easy as long as you have someone who can program MFC.

name withheld out of cowardice
Tuesday, June 22, 2004

what's invokeLater?

/Java noob

muppet from forums.madebymonkeys.net
Tuesday, June 22, 2004

Let me guess, some smexpert has talked to your CEO on the links and told him that all their MFC apps run really fast and are cheap to develop.

I'm no real fan of Java, but this really sounds like huge waste of time.

By the way, did you read Joel's screed on how memory management saves time? Two things, your performance/memory problems may be a result of abuse of the automatic memory management. Secondly, manual memory allocation may result in a faster app, but it takes a lot more programmer time to do it.

MilesArcher
Tuesday, June 22, 2004

Have you looked at SwingWT ( http://swingwt.sourceforge.net/ ) ? Perhaps it can give you the performance gain you seek with less re-coding.

Kura-Kura
Tuesday, June 22, 2004

Maybe try Eclipse/SWT first, before rewriting in MFC?

Eclipse 3.0 comes out real soon now, and includes support for Swing and SWT used simultaneously.

(SWT is the Eclipse version of Swing. It uses native widgets/controls, wrapped in JNI, and thinly wrapped in Java).

AnMFCAndJavaProgrammer
Tuesday, June 22, 2004

I put this question in the "if you have to ask..." category.

Bill Rushmore
Tuesday, June 22, 2004

"Hell, I can write a report in two days."

Bah, I can write a report in an hour, you must be writing the reporting tool, such as Crystal Reports also I guess.

Mike
Tuesday, June 22, 2004

JGoodies -- still the best Swing libs? Try the demo and see what you think.

Tayssir John Gabbour
Wednesday, June 23, 2004

The perennial Swing problem - performance.

IntelliJ IDEA is, as far as I can tell, a Swing application and it is blindingly fast. I don't know how they did it. I find it:
* damn impressive
* encouraging to see that with some forethought Swing apps can have good performance

Herr Herr
Wednesday, June 23, 2004

IntelliJ is fast for a Swing application, but as an IDE it doesn't go anywhere near VStudio.

RP
Wednesday, June 23, 2004

You guys seem to have a bias against MFC, strange.
It is not really so hard to learn it. If you just use what the framework givest you, there are few problem.

The problems start, when you want to do your own non
stanard stuff/something slightly different than what the framework does. Here you need to understand message routing + read a bit of MFC source code, but it's also not soo hard.

I think that debugging MFC applications is easier then doing java, you have the message spy (no such thing with swing). You don't have to do a thousand listener classes (even if they are nested). A dialog based application (with app wizard) is much easier then doing pannels in java.
Dialog/resources are something that Swing does not have (don't know why)

and anyway, i think that you can make any application slooow. you just need to know how.

Michael Moser
Wednesday, June 23, 2004

Now you got me curious: how hard would it be to go from Swing to MFC? Better yet, what are the big differences between those libraries, and if those are that many, what do they have in common?

RP
Wednesday, June 23, 2004

Trust me, you really don't want to move to MFC. Not from _anything_.


Wednesday, June 23, 2004

Then, if you want to develop fast and light native applications on Windows, what do you use? Now, let's pretend Delphi doesn't exist, of course...

RP
Wednesday, June 23, 2004

Well "fast and light" and MFC don't really go together anyway, at least not the "light" bit. Maybe wxWindows? Heck, roll your own. The chances are that you won't use half the MFC stuff anyway.


Wednesday, June 23, 2004

Hmmm, but aren't wxWindows's widgets a bit too clunky? What if I want something with the Look & Feel of Visual Studio?

RP
Wednesday, June 23, 2004

I haven't actually tried wxWindows, that's why I put a "?" after it.

To be honest I'd probably do it in Java these days...


Wednesday, June 23, 2004

invokeLater is one of the methds one uses when creating a responsive Swing app.  Say your app accesses a server that might not return in less than a second.  You put that request in a separate thread so your swing app doesn't hang.  When the server request returns, if you want to redraw the GUI to reflect information returned from the server, the thread you created to talk to the server passes a Runnable to the invokeLater method and that Runnable gets qeued up to be executed in the thread that is allowed to update the GUI.

Basically you need to read the articles on using threads in Swing.

This problem is not unique to Swing.  Outlook, a Microsoft Office application, hangs all the time- whenever the server is messed up I can't do a thing with it.  I doubt just moving to MFC will stop your app from hanging.

name withheld out of cowardice
Wednesday, June 23, 2004

> I doubt just moving to MFC will stop your app from hanging.

Yes: the Windows GUI itself is single-threaded for a given application (in the underlying Win32 API, not just in the MFC class library that sits on top of Win32).

You can use worker threads, which on completion then invoke the thread that owns the GUI (via the "PostMessage" API or similar), so that the GUI remains responsive while the worker threads are busy ... which is presumably analous to the Swing "invokeLater" (or analogous to the .NET "Control.Invoke" method).

Christopher Wells
Wednesday, June 23, 2004

Since you're already depending on a runtime why not go straight to .NET and Windows Forms?  You don't get quite the performance and flexibility you could theoretically get with MFC but since you're new at this stuff anyway you'll likely get better results.

Chris Nahr
Wednesday, June 23, 2004

Chris Nahr, I'm sorry, but for us performance *is* critical. We developed our application in Swing because the product was suppose to be a one-off to be used by a few people who wanted something more responsive than webapps; and because all of us were sever-side java developer, so the learning curve was not too steep.
But now the product has matured, and the need for a speedier UI surfaced. Some of us thought about MFC, so we could get a look and feel similar to modern MS applications. And because C++ is as snappy as they come.

RP
Wednesday, June 23, 2004

I afraid if you don't really know what is causing your slowdowns / memory usage, the conversion may be big waste of time. There could be many other bottlenecks besides the UI.

DJ
Wednesday, June 23, 2004

Yeah, you should try out stuff like lazy loading... if a huge startup is the problem. Init stuff (which aren't needed immediately) in a behind-the-scenes thread.

Tayssir John Gabbour
Wednesday, June 23, 2004

"Hmmm, but aren't wxWindows's widgets a bit too clunky? What if I want something with the Look & Feel of Visual Studio?"

Its "widgets" are simply wrappers for native widgets, except when the native platform doesn't have a particular widget (mostly a problem with Motif).

The look-and-feel seems pretty XP-ish to me:

http://www.anthemion.co.uk/dialogblocks/screenshots.htm

Or do you mean something else by "clunky"?

Mr. X
Friday, June 25, 2004

Now I have not used it, but have you looked at Foxtrot:
http://foxtrot.sourceforge.net/

Mike Fuller
Tuesday, August 10, 2004

*  Recent Topics

*  Fog Creek Home