Re: Cocoa/Windows parallel dvlpmt
Re: Cocoa/Windows parallel dvlpmt
- Subject: Re: Cocoa/Windows parallel dvlpmt
- From: Andy Satori <email@hidden>
- Date: Mon, 2 Feb 2004 13:53:17 -0500
Comments inline:
On Feb 2, 2004, at 12:19 PM, Erez Anzel wrote:
Why did you use plain vanilla Win32 instead of MFC? I have a fair
amount of UI in my CAD-like app, and am looking for the fastest and
easiest route to port to Windows. I figure on using Visual C++ and
MFC, but I'm basing that on no real knowledge or experience.
MFC is the *quick* way to generate UI's in Visual C++ (Studio), but MFC
is infamous in the Windows community for bloat and leaks. It doesn't
take too long to do the same work using vanilla C Win32 calls. Notice
I said, C, not C++. the Win32API is a C API (with alot of Pascal
calling conventions just for fun).
I'm not sure about efficiency: at what level should I draw the line
between Cocoa and STL? For instance, should my MVC model (containing
perhaps as many as 100,000 objects) use an STL vector for those
objects? Or should it keep an NSMutableArray for the Mac, and
something else for Windows?
I would implement this using a Vector. In my specific case here, I
have a wrapper class that I use to allow Cocoa apps to to consume my
C++ class where I needed this behaviour, it looks like a MutableArray
in function calls, but is in fact using the C++ class to return the
data elements, like count, objectAt etc..
If an STL vector, then how should I tell each object to draw itself in
the NSView subclass which I (currently) pass it? (I can have multiple
views, each displaying all of the objects simultaneously.) When my
data changes, I typically iterate first through the views; each view
then tells the model to redraw its objects, passing it the view so
that the objects will know the drawing scale etc. (each object knows
its real-world coordinates, not its window coordinates). (Often a
change in one data object requires much (if not all) of each view to
be redrawn due to impact on other objects.) Maybe I should be passing
specific view parameters, instead of the platform-specific view
object. The data object's drawMyself method can call platform-specific
scaling and drawing methods depending upon the platform (determined at
compile time).
Again, I use thin wrapper classes where it's required, however, I'm not
sure you need them in this instance. I'd probably just use .mm files
and use the C++ object directly from my Cocoa Objective C classes, the
downside being that you can toll free bridge a vector to a Native
Object like an NSArray.
Help wanted: Any advice on whom to turn to, or how to find someone to
turn to, to help with the design and porting? I'm in Toronto, Canada,
but I suppose a long-distance relationship can also work.
I'm certainly not available full-time, but for questions like these,
I'm more than willing to provide thoughts and direction.
One of the things that you may want to take a good look at is using the
WTL with ATL instead of MFC for your Windows front end. These two
technologies are STL like implementations of the Win32 API that may be
better suited to your needs, and they both support Visual Studio / C++
GUI development tools, which are anemic at best, but anything is a
start, they also provide you with a nice bridge to COM objects and
interfaces as needed.
I have to be honest though, coming from the Windows world, XCode and
Interface Builder are just damn elegant and fun tools to use.
Andy
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.