MFC under VS2010
in [MFC]
|
Prev: MDI App: start 2 DocTemplates in CMyApp::InitInstance
Next: How To: CStatubar panel Right-align text
From: David Ching on 31 Mar 2010 11:48 "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message news:Xns9D4C18BC787B7MihaiN(a)207.46.248.16... > > As a result we will have not Opera, no Firefox, and possible no Flash on > the new mobile devices (unless MS decides to make some exceptions). > Opera and Firefox are no great loss if the built-in browser is decent. For example, on Blackberry, the built-in browser does not do Javascript and is entirely inadequate. As for Flash, it does seem it is getting frozen out, first on iPad, now on Win Phone. Perhaps Adobe will get into the smartphone business to promote Flash! :-O -- David
From: Hector Santos on 31 Mar 2010 12:41 Goran wrote: > On Mar 30, 7:42 pm, "Tom Serface" <t...(a)camaswood.com> wrote: >> I just worked on another complete .NET application and since it was very >> file system intensive I had to resort to pInvoking all sorts of Win32 >> functions since the .NET System.IO implementation can't support file paths >> longer than 260 chars. > > Bloody hell, as a Brit would say! Out of curiosity, and if you don't > mind, what's the problem!? (You can point me to the offending IL if > that's easiest). > > Goran. When I first read him say this, I suspected maybe its a unicode vs mbcs thing. -- HLS
From: David Ching on 31 Mar 2010 14:28 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:euc4r5dtrah9m7altmoot415ta5jf2l6ai(a)4ax.com... > I agree. I feel culturally displaced because I don't know WPF. But I > have difficulty > justifying it because my customer base is purely C/C++ based. But I > really think I should > be learning it. > **** > I am kept sufficiently busy with C/C++ work that I don't have spare time > to learn WPF. I > keep feeling this is going to come back and bite me soon. > **** > Sadly, these myths persist. My clients don't want C# because they have no > in-house people > to maintain the code (having ONLY C/C++/MFC experts) It's always hard to predict paradigm shifts and react in a timely fashion. It seems your steady work with C/C++ coupled with your eye on retirement makes sticking with MFC until its logical conclusion a good choice for you. OTOH, with the good books on WPF coming out now, the "barrier to entry" is coming lower, so you might want to start reading about it for your own edification, and it might turn into some gigs in the future, who knows. -- David
From: Hector Santos on 31 Mar 2010 16:06 +Ajay Kalra wrote: > On Mar 30, 7:37 am, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: > >> For the past three years, it's been very difficult for me to find Win32/MFC >> jobs here in the Bay Area. Mostly all the job ads for Windows client want >> at least some .NET experience, and most of them are interested ONLY in .NET. >> C++ is still used for cross platform or embedded, but then we are not >> talking about Windows. And it's not just me. I have former colleagues who >> have been programming MFC (and MFC only) for the last decade who are now >> having difficulty being attractive in the job market. > > This has been my experience as well. When we hire for GUI, we only > look for .Net. (C++ isnt even looked at). I havent seen a MFC job > opening in years.It has been nothing but .Net for a long while. Ok, I am going to write this long message once to get in my thoughts here over the whole subjective issue. It all highly subjective and personal and what/which direction you go or where you are at is subject to your history or position in all this. It really all depends on where you are looking. There are plenty of definitely MFC, C/C++ jobs availability. But keep in mind, these tend to demand more salary, more systems level experience. What you are really seeing, in general, not specifics, is requirements for a broad knowledge of various technologies, because it is pretty broad. I personally can not afford just hiring a .NET person unless he has a sound general broad understanding of basic MFC, C++. So while I might hire him to take him to the next level, he needs to be able to solve problems where necessary and be able to understand (not be confused) when speaking MFC. ..NET GUI works because of the hardware and OS caching speed advancements in speed which allows for dealing with a p-code environment, but if you have faster needs or parts, or basically lower overhead needs, then you have to be more tuned with these methods or at least have someone (the more experience honcho) on board that will provide the system related tools and apis for you. Thats one of the issues we have in committing to .NET languages. We have already have a huge investment C/C++, MFC and in additional libraries, methods, classes, API, a good bit of it designed for speed, low overhead. This was a very important part in the lower cost development behind reusability. But that is also the purpose of the higher level IDE gui environment. The nice thing about .NET is that its very rich and it does cover a good bit of these needs with the .NET libraries. However, not in all cases. For example, for us, many of our applications have large data handling requirements, i.e, electronic mail, conference mail, group ware, file uploads, downloads libraries, etc. Much of this is handled with memory file maps. Native MMF system .NET library functionally was not added until .NET 4.0. Sure, you can write the pinvoke code it yourself or use the 3rd party classes out there for it, I think I even saw one for .NET ported from one for VB.Classic. But overall, it was another reason to not commit to .NET yet because there are other things in .NET 4.0 that was desirable. Its a moving target so that doesn't help businesses that need to think about these things. Of course, if you (speaking in general) are dealing with in-house products or specific market products with no legacy customer to support, then you have all the luxury in the world to use the latest and greatest without impediments. Unless you have a specific design reason to develop the fastest code possible, have no issues on what is required to be installed on user machines, then using .NET makes perfect sense. The other issue, for us at least, is that we have a multi-device requirement. This is not a design requirement for many developers. We have a commercial online hosting system that customers from small to large install for their own customer support or public, private hosting (intranet) system. They need may need Dialup and internet access using any kind of user device. Most of our customers started as Dialup only. By the time the internet came around, as early corporate mandates and their own customers did not yet demand internet access. That changes slowly over the years and for our customers all they had to do was turn on the internet servers and the entire I/O was virtualized. So what you see and do via dialup is the same via any other TCP/IP connection device. The interface is the same, the communications is virtualized. A good picture of this multi-device design is shown here: http://www.winserver.com/public/vimg.wct?src=wcrpcnet7.png The Yellow Parts is our framework now since 1996 The light yellow and green parts are under developed. Once done, any clients can be used, at least that is the plan. :) The problem we have is how to best single source it or: What languages do you use to not only create the client GUI but to interface in Interactive fashion as oppose to client/server fashion? The key is interactive two way communications or FULL DUPLEX. The WCGUIAGT server on the backend is our special Java client GUI controller. For the new clients we need something that does it with XML and/or JSON which we call the WCRPC bridge. The question i need to explore is how WPF fits it with this bridge. I believe it does just based that I think its is XML based. I have not studied it yet, but MS might have their own "bridging technology," in fact, I am pretty sure their have a protocol here. I've been in this business a long time, in fact, among the early pioneers, the history of this (intelligent frontends) can be crudely summarizes: o Generic Server, TGUI (Text/Graphical User Interface) client - Telecommunications products User Interface scripting languages. These were trained to watch for server side prompts and display client side dialogs, etc. Whats your user login id? The user does not see this, but a dialog, but the script looks for the the whole string or part of it. Two problems: script timing misfiresl; text prompts changed. - To speed it up, reduce misfirsts and to avoid text prmpt change issues, advanced hosting servers uses persistent tags: [LOGIN]Enter your user name or id? So client scripts just had to be trained to look for [LOGIN]. Early version of this on a public hosting systems was for CompuServ using TapCis and there was one lost fella/friend that use trhe Turbo Powers OWL library to write one TGUI for CompuServe. o TGUI Client/Server - Pre HTML Special clients now begin to use special servers with a persistent tag or Output language to help draw the client interface and also have interactive I/O. Early versions of this where the Minitel, Prodigy, etc. Others such as the vendors at the last ONE BBSCON show, renamed to ONE ISOCON trade show, introduced - RIP, this was a LANGUAGE of tags to be used on text based servers. [RIP_LOGINBOX]What is your user name? So if you had telecomm program that supported RIP, it will display the login box. - RoboFX, this uses Windows Graphics and Glyphs designed by a 17 yrs old. - GoldXpress (Moi!, A layer above our Silver Xpress Mail System) Ironically, at this last ONE BBSCON show was the odd excitement in the trade show air about this new "technology" that was going to rule the world. No one had a demo or booth, but Vince Cerf gave a talk about the "internet" and someone else talk about this "HTML" thing. I knew (read/heard about it) but it was "academia" and was too excited about the RIP. In fact, our Wildcat! DOS version was the first commercial BBS software to support RIP. So when you connect to a wildcat! host, it spits out ANSI/VT100 and RIP escape reporting codes and the Telecomm program will detect it. If the telecomm didn't support it, then plain old text interface was used. o HTML world I don't need to say much here, but by 1994 the MAD RUSH was on by establish BBS vendors to: - Move to WIndows - Compile under 32 bit - Support HTML interface and the new device with WEB browsers. in 1996, Wildcat! DOS was ported to Wildcat! Interactive Net Server (WINSERVER) as the first system that combined the dialup and internet world to support: - Text mode - Native GUI mode with our Wildcat! Navigator frontend, free to users - Web Interface. HTML killed RIP, never took off and RIP was pulled from the text mode interface. While Javascript and AJAX with HTML offered increases "WEB 2.0" designs, people still knew there was a POWER in making the client smarter with better GUI and dynamic interactive I/O; - Flash, ActiveX, Java client side agents In short, MS fell behind and .NET and ASP was their efforts here. But ASP is still based on HTML. Then you have the growth of APPLE and Objective-C methods. 2000 was a lost decade for me for all these issues reasons - how do what single source this, how do we offer an API that allows customers to do this for any device? Because it was a moving target and we already had a solid working solution - getting older day, it was not so simple to commit to WINFORM or ASP for anything we need. Microsoft decisions for long term strategy for MFC was horrible. They didn't think about a good migration approach where I think most of the MFC-based applications would look at a sub-system transparent and passive convergence of COM and .NET integration. Just consider that a MFC product would have maybe Windows 2003+ user requirements anyway or ..NET installation for another part of their stock products. Microsoft should of leverage this better. That is why I asked about VS2010 and MFC. Rhetorically, did Microsoft say? Ok, we forgot about you guys this decade, sorry! VS2010 is the new VS98 and MFC IDE support is back and better, but it MAY mean additional distribution requirements when you use any of the components and controls in your GUI toolbox that are now a natural part of the inherent, out of the box tool box set. What I did know and was very wary about it was that the I/O server/client communications was XML based. Just like Mozilla did for their stuff, just Adobe did for their Apex stuff, just like everyone was heading to with the new XML based GUI designer system. I didn't installed SilverLight but I also thought it was XML based. I just installed it the other day, I gave up arguing and fighting the idea that Microsoft really really really wants to make you part of their centralized farm network, just like Google and Apple has open the door. In fact, the concern is not just mine. The US congress is finally going to rethink how the 1986 US EPCA provisions written to address the then new 1980s Online BBS hosting market is today outdated for the centralized and integrated cloud world. http://www.nytimes.com/2010/03/31/technology/31privacy.html WP7 is Microsoft answer to Apple efforts. Not because they didn't know about this, but APPLE, not treated as a monopoly was able to change the mindset of the world, with little, short 2 weeks of complaining, that its OK to take force 1 way to develop and 100% control of what is allowed to run, and do so with a business model to charge a ROYALTY for offering an applet on its network. MS is going to use the same model which was only possible because of APPLE. What isn't know is how developers will react to this. I personally think its just another cycle. In our BBS world, the top vendors had their own p-code api for 3rd party developers to right applications that run on at the server. We just didn't charge a royalty, however, they had to purchase the SDK tool kit, the SDK was free, but the tool kit wasn't - a long term issue of whether to start giving it away as we lost market share. Its the old Gillette business model theory: Do you give away (small cost) the "razor" and sell, make profit on the blades? Monopolies or better described as Oligopolies, Collusion models, don't have to give away the toolkit. Today, Microsoft charged you for the toolkit and had no say on the end-product you wrote with it. The traditional model. We can also say that developing with WPF is the still the same model, but if you target it for WPC7 devices, then its different model. What will MS do with WP7 business model as the new cellular devices move towards (and already became) the new handheld PC, only time will tell. All I can say, for us, 2000 was somewhat of a "lost decade." I started worthing with it in 2005, then again in 2008, but didn't commit to it. Today we can probably say the new era is becoming more feasible again. WPF is the new way to the the TGUI that began as: What is your Login name? Only faster speeds and offloaded technology SilverLight, today make this possible. -- HLS
From: Mihai N. on 1 Apr 2010 04:04
> Opera and Firefox are no great loss if the built-in browser is decent. But (historically) the IE mobile was not decent. Point is: a lot of other potentially nice applications will be left out. Anything that is C++ and not a toy application (anything with many tens, if not hundreds of thousands of lines of code). One needs a very strong incentive to rewrite the whole beast. So let's recap the story as I see it: - force developers to rewrite everything in a programming language invented by me, which can't be used for anythign cross-platform (Apple: Objective C, MS: C#) - no multitasking (both Apple and MS) - lock-down the thing and only allow applications to be installed they my proprietary app-store (both Apple and MS) So haw is just copying the strategy applied by the leader going to topple the leader, with some years handicap already. What is the differenciating factor? Why would I do a full rewrite from C++ to C# to work on a new unproven platform, instead of just rewrite the GUI in Objective C and run on the platform that is number one? (you can still use C++ on iPhone and iPad) Personally, I was waiting for Win Mobile 7 for the freedom to install what I want. So much for it. Now Android looks better. Mihai |