Speaking of VS2005
-
Why is it that on my work desktop machine, I can drag items from the data sources window onto windows forms with no problem, but on the laptop, as soon as I switch to design mode on the form, the contents of the Data Sources window disappear? One more reason to spend my own money on a MacIntel rather than VS..... if(E_NOINTERFACE == pThat->QueryInterface(IID_IUnknown,(void**)&pUnk)) { // I aint no pUnk bitch! }
-
Why is it that on my work desktop machine, I can drag items from the data sources window onto windows forms with no problem, but on the laptop, as soon as I switch to design mode on the form, the contents of the Data Sources window disappear? One more reason to spend my own money on a MacIntel rather than VS..... if(E_NOINTERFACE == pThat->QueryInterface(IID_IUnknown,(void**)&pUnk)) { // I aint no pUnk bitch! }
Well before you gripe too much about VS, and whatever oddities it may or may not have, do try using OS X's devtools on a reasonably large project that's C++. You'll find few things to like. And while it get's a little better if you just stick to either plain C for command line tool stuff, or Cocoa for UI, Mac only projects, it sure as hell isn't the garden of paradise many would have you believe. Specifically: - The compiler/linker toolchain just sucks. It's slow to compile, and it's performance is not exactly stellar. It will be interesting to compare similar codebases produced by GCC on INtel OSX vs those made by VC on Win32. In exe performance comparisons between GCC and VC 7/7/whatever GCC tends to get spanked pretty hard. -The GUI builder tool (Interface Builder - IB) *looks* pretty. And if you *play* with it, it looks neat. Then when you really start to use it, it doesn't scale that well. Look on some of the dev mailing lists and you'll hear a lot of buggy complaints with IB. For example, you put a button on a window. In VS .Net (or Delphi for that matter) hooking up that button to a chunk of code is at worst 2-3 mouse clicks away. The IDE's understand the proper linkage between UI resource and source code, i.e. they create the appropriate stub for you function call for you on the fly, unless you pick an existing one. IB cannot do this AT all, unless you already have a handler (I believe they are called "outlets", could be wrong on the exact terminology ). It cannot create ANY code for you whatsoever. You have to manually create any class skeletons, functions, etc yourself. Another annoying fact is the UI for changing various options, while "pretty" is annoying because it can change drastically for each element, different options may be in different places, etc, and it's a pain to get used to. And keep in mind that what little integration it does have is reserved ONLY for Cocoa/ObjectiveC based projects. If you use C++/C and Carbon, your SOL, you have to wire all the event handling code to widgets manually, in code. And keep this in mind - IB dates back to NeXTStep, at least to 1991 (and maybe earlier, I'm not sure), I used it back in 1995-96 and many of the gripes I have now, STILL exist in the current version! -XCode, the IDE piece, is not that fast in terms of performance, and can be fairly buggy on it's own. While the 2.x series is better than the 1.x series in terms of not crashing (I could regularly crash XCode 1.5 at random 3-4 times in a multi hour session), it's not amazing. The keybindin
-
Well before you gripe too much about VS, and whatever oddities it may or may not have, do try using OS X's devtools on a reasonably large project that's C++. You'll find few things to like. And while it get's a little better if you just stick to either plain C for command line tool stuff, or Cocoa for UI, Mac only projects, it sure as hell isn't the garden of paradise many would have you believe. Specifically: - The compiler/linker toolchain just sucks. It's slow to compile, and it's performance is not exactly stellar. It will be interesting to compare similar codebases produced by GCC on INtel OSX vs those made by VC on Win32. In exe performance comparisons between GCC and VC 7/7/whatever GCC tends to get spanked pretty hard. -The GUI builder tool (Interface Builder - IB) *looks* pretty. And if you *play* with it, it looks neat. Then when you really start to use it, it doesn't scale that well. Look on some of the dev mailing lists and you'll hear a lot of buggy complaints with IB. For example, you put a button on a window. In VS .Net (or Delphi for that matter) hooking up that button to a chunk of code is at worst 2-3 mouse clicks away. The IDE's understand the proper linkage between UI resource and source code, i.e. they create the appropriate stub for you function call for you on the fly, unless you pick an existing one. IB cannot do this AT all, unless you already have a handler (I believe they are called "outlets", could be wrong on the exact terminology ). It cannot create ANY code for you whatsoever. You have to manually create any class skeletons, functions, etc yourself. Another annoying fact is the UI for changing various options, while "pretty" is annoying because it can change drastically for each element, different options may be in different places, etc, and it's a pain to get used to. And keep in mind that what little integration it does have is reserved ONLY for Cocoa/ObjectiveC based projects. If you use C++/C and Carbon, your SOL, you have to wire all the event handling code to widgets manually, in code. And keep this in mind - IB dates back to NeXTStep, at least to 1991 (and maybe earlier, I'm not sure), I used it back in 1995-96 and many of the gripes I have now, STILL exist in the current version! -XCode, the IDE piece, is not that fast in terms of performance, and can be fairly buggy on it's own. While the 2.x series is better than the 1.x series in terms of not crashing (I could regularly crash XCode 1.5 at random 3-4 times in a multi hour session), it's not amazing. The keybindin
I agree. XCode is no where near Visual Studio's level. Although its distributed build option is nice. The Shark profiler is nice too.
-
Well before you gripe too much about VS, and whatever oddities it may or may not have, do try using OS X's devtools on a reasonably large project that's C++. You'll find few things to like. And while it get's a little better if you just stick to either plain C for command line tool stuff, or Cocoa for UI, Mac only projects, it sure as hell isn't the garden of paradise many would have you believe. Specifically: - The compiler/linker toolchain just sucks. It's slow to compile, and it's performance is not exactly stellar. It will be interesting to compare similar codebases produced by GCC on INtel OSX vs those made by VC on Win32. In exe performance comparisons between GCC and VC 7/7/whatever GCC tends to get spanked pretty hard. -The GUI builder tool (Interface Builder - IB) *looks* pretty. And if you *play* with it, it looks neat. Then when you really start to use it, it doesn't scale that well. Look on some of the dev mailing lists and you'll hear a lot of buggy complaints with IB. For example, you put a button on a window. In VS .Net (or Delphi for that matter) hooking up that button to a chunk of code is at worst 2-3 mouse clicks away. The IDE's understand the proper linkage between UI resource and source code, i.e. they create the appropriate stub for you function call for you on the fly, unless you pick an existing one. IB cannot do this AT all, unless you already have a handler (I believe they are called "outlets", could be wrong on the exact terminology ). It cannot create ANY code for you whatsoever. You have to manually create any class skeletons, functions, etc yourself. Another annoying fact is the UI for changing various options, while "pretty" is annoying because it can change drastically for each element, different options may be in different places, etc, and it's a pain to get used to. And keep in mind that what little integration it does have is reserved ONLY for Cocoa/ObjectiveC based projects. If you use C++/C and Carbon, your SOL, you have to wire all the event handling code to widgets manually, in code. And keep this in mind - IB dates back to NeXTStep, at least to 1991 (and maybe earlier, I'm not sure), I used it back in 1995-96 and many of the gripes I have now, STILL exist in the current version! -XCode, the IDE piece, is not that fast in terms of performance, and can be fairly buggy on it's own. While the 2.x series is better than the 1.x series in terms of not crashing (I could regularly crash XCode 1.5 at random 3-4 times in a multi hour session), it's not amazing. The keybindin
having a bad day? :rolleyes:
Some of us walk the memory lane, others plummet into a rabbit hole
boost your code || Fold With Us! || sighist -
Why is it that on my work desktop machine, I can drag items from the data sources window onto windows forms with no problem, but on the laptop, as soon as I switch to design mode on the form, the contents of the Data Sources window disappear? One more reason to spend my own money on a MacIntel rather than VS..... if(E_NOINTERFACE == pThat->QueryInterface(IID_IUnknown,(void**)&pUnk)) { // I aint no pUnk bitch! }
sadly, you probably told it that you want it to. Highly configurable UI ==> highly unstable UI
Some of us walk the memory lane, others plummet into a rabbit hole
boost your code || Fold With Us! || sighist -
having a bad day? :rolleyes:
Some of us walk the memory lane, others plummet into a rabbit hole
boost your code || Fold With Us! || sighist -
Well before you gripe too much about VS, and whatever oddities it may or may not have, do try using OS X's devtools on a reasonably large project that's C++. You'll find few things to like. And while it get's a little better if you just stick to either plain C for command line tool stuff, or Cocoa for UI, Mac only projects, it sure as hell isn't the garden of paradise many would have you believe. Specifically: - The compiler/linker toolchain just sucks. It's slow to compile, and it's performance is not exactly stellar. It will be interesting to compare similar codebases produced by GCC on INtel OSX vs those made by VC on Win32. In exe performance comparisons between GCC and VC 7/7/whatever GCC tends to get spanked pretty hard. -The GUI builder tool (Interface Builder - IB) *looks* pretty. And if you *play* with it, it looks neat. Then when you really start to use it, it doesn't scale that well. Look on some of the dev mailing lists and you'll hear a lot of buggy complaints with IB. For example, you put a button on a window. In VS .Net (or Delphi for that matter) hooking up that button to a chunk of code is at worst 2-3 mouse clicks away. The IDE's understand the proper linkage between UI resource and source code, i.e. they create the appropriate stub for you function call for you on the fly, unless you pick an existing one. IB cannot do this AT all, unless you already have a handler (I believe they are called "outlets", could be wrong on the exact terminology ). It cannot create ANY code for you whatsoever. You have to manually create any class skeletons, functions, etc yourself. Another annoying fact is the UI for changing various options, while "pretty" is annoying because it can change drastically for each element, different options may be in different places, etc, and it's a pain to get used to. And keep in mind that what little integration it does have is reserved ONLY for Cocoa/ObjectiveC based projects. If you use C++/C and Carbon, your SOL, you have to wire all the event handling code to widgets manually, in code. And keep this in mind - IB dates back to NeXTStep, at least to 1991 (and maybe earlier, I'm not sure), I used it back in 1995-96 and many of the gripes I have now, STILL exist in the current version! -XCode, the IDE piece, is not that fast in terms of performance, and can be fairly buggy on it's own. While the 2.x series is better than the 1.x series in terms of not crashing (I could regularly crash XCode 1.5 at random 3-4 times in a multi hour session), it's not amazing. The keybindin
Jim, very interesting review of the MAC platform from a developer’s perspective. 5 I have no desire to learn anything about developing for MAC’s but for me switching from VS6 to VS2005 C++ & MFC it feels like a few steps back. I have resigned to doing message maps by hand as it’s quicker and actually works that way. Figuring out how to do installers is a Royal PTA. X|
-
having a bad day? :rolleyes:
Some of us walk the memory lane, others plummet into a rabbit hole
boost your code || Fold With Us! || sighistMan last weekend (i.e. Late Sat night and sunday) totally sucked. I went to bed pissed as hell because I couldn't figure out why I was having so many problems, and then when I found it, it was a bigger pain to verify that the fix was kosher because it took so long to re-compile and link everything. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
Jim, very interesting review of the MAC platform from a developer’s perspective. 5 I have no desire to learn anything about developing for MAC’s but for me switching from VS6 to VS2005 C++ & MFC it feels like a few steps back. I have resigned to doing message maps by hand as it’s quicker and actually works that way. Figuring out how to do installers is a Royal PTA. X|
S Douglas wrote:
I have no desire to learn anything about developing for MAC
Well I wouldn't write it off that quickly. The Cocoa framework really has a *lot* of cool design ideas and features. It's well worth looking at to see how they designed it. It's too bad that the actual tools are so sub-par - the framework is most definitely NOT sub-par. ObjectiveC has a lot of *really* cool features that go sadly unnoticed because there's no Win32 presence, and few windows developers know about it. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
S Douglas wrote:
I have no desire to learn anything about developing for MAC
Well I wouldn't write it off that quickly. The Cocoa framework really has a *lot* of cool design ideas and features. It's well worth looking at to see how they designed it. It's too bad that the actual tools are so sub-par - the framework is most definitely NOT sub-par. ObjectiveC has a lot of *really* cool features that go sadly unnoticed because there's no Win32 presence, and few windows developers know about it. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
Jim Crafton wrote:
The Cocoa framework really has a *lot* of cool design ideas and features.
Oh I don't doubt it. However, the sheer cost of a MAC is beyond what I’m willing to pay. Besides I detest the MAC UI, looks something like what I would expect Fisher Price to create...(I know that comment is going to generate a 1 but I dont care) Yes I know MS is heading down that same path but we aren’t there yet. Besides my W2K boxes still work and run like champs. Maybe once MACs are fully on Intel and I can build my own box oh and I can turn the Fisher Price UI :) off, I will look at it. Till then...
-
Jim Crafton wrote:
The Cocoa framework really has a *lot* of cool design ideas and features.
Oh I don't doubt it. However, the sheer cost of a MAC is beyond what I’m willing to pay. Besides I detest the MAC UI, looks something like what I would expect Fisher Price to create...(I know that comment is going to generate a 1 but I dont care) Yes I know MS is heading down that same path but we aren’t there yet. Besides my W2K boxes still work and run like champs. Maybe once MACs are fully on Intel and I can build my own box oh and I can turn the Fisher Price UI :) off, I will look at it. Till then...
Heh, if you dislike the Mac UI, you're going to HATE Vista :) Yeah I'm with you on windows - I have XP, but I never use it, I much prefer to use Win2K.
S Douglas wrote:
Maybe once MACs are fully on Intel and I can build my own box oh and I can turn the Fisher Price UI off, I will look at it.
That will never happen. At best you'll be able to buy a Mac and run windows on it (dual boot), but you won't be able to just build your own whitebox PC and load up OSX (at least not legally). ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
Heh, if you dislike the Mac UI, you're going to HATE Vista :) Yeah I'm with you on windows - I have XP, but I never use it, I much prefer to use Win2K.
S Douglas wrote:
Maybe once MACs are fully on Intel and I can build my own box oh and I can turn the Fisher Price UI off, I will look at it.
That will never happen. At best you'll be able to buy a Mac and run windows on it (dual boot), but you won't be able to just build your own whitebox PC and load up OSX (at least not legally). ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
Jim Crafton wrote:
Heh, if you dislike the Mac UI, you're going to HATE Vista
I know I have seen some of the screen shots. Really who is the marketing rep that decided to go to Walt Disney / Fisher Price and let them design the new UIs? I’m hoping that MS will hold true to backwards compatibility and allow end users to turn that crap off, much the same as XP. Maybe it’s just me but when I see one a MAC boot I expect it to play “M-I-C-K-E-Y M-O-U-S-E, Mickey Mouse” etc..
Jim Crafton wrote:
but you won't be able to just build your own whitebox PC and load up OSX (at least not legally).
Well looks like I won't be venturing into Steve's camp then at all, eh?
Jim Crafton wrote:
At best you'll be able to buy a Mac and run windows on it (dual boot),
I would rather Dual boot *Nix & Windows. At least I can do what ever I want with a *Nix box. It’s to bad MS ended support for the PowerPC processor, now that would be worth the price of admission.