@JoshRoss:Make it 8.2 will make Vista goes out of support window too. As many companies are starting moving to Win7, this will make them have a hard time to explain to the management why they plan to move on to an "about to expire" platform, and it's certainly a great way to annoy the IT professionals.
I heard people talking about Win8.1 update 1 will bring back IE8 compatibility mode for IE11. Can anyone confirm/reject this?
It means a lot to us web programmers. For the least one, when asking about broken web pages, when we heard them using IE11 we'd need to ask whether the user is using Win8.1. And btw, this will surely allow more leeway for updating web applications to support IE10+.
@magicalclick:For one thing, I agree with you until the user needs freezed pane on grids, something I'd rather let the component writers do instead of me.
For the others, if you need things like simple inline editing grid you'd better code it yourself. Most grids out there are expecting "row edit" so if your requirement says to save in a page and don't need to click another button for "edit mode" (just like in WinForm), you'd to expect adding roughly the same amount of code as you write it from scratch in order to patch the grid for the purpose.(Especially if your grid has total/subtotal fields)
The question of whether to use 3rd party controls on web really gives me mixed feelings.
@RealBboy360: I disagree for the second point and will give an example.
My company is planning to buy a bunch of iPads for QAs to use when walking around the factory. They need to use it to access an inhouse web application of my company. When they use it, they're complaining the menus are too small for them to press.
When I look in IE and Firefox, the menu looks okay. Until I figured that the iPad uses Safari and maybe we should test under it too, we found out that the ASP:Menu control is rendered as DIV in IE/Firefox but render as SPAN tag only in Safari, therefore the menuitems only get single line height. We have to add CSS for that menu ID + SPAN to address that and now the application looks the same at these browsers again.
So you should really worry about how the controls are rendered in all of your supported browsers.
I don't know, but since while OpenCL have built in interop for OpenGL, maybe it's time to also make DirectX interop into the standard, or rather, make OpenCL support into DirectX requirement (Ok, maybe not OpenCL if you don't like it. Replace it with whatever parallel processing library that uses GPU power if you want).
That'd be a more meaningful move instead of just blindly expanding the APIs without good reason.
@davewill:You have to use fairly old IE versions (my company still enforce IE8 as standard here) to see it. I haven't seen it at home since I moved to IE10.
When opening the site in Firefox, Safari, etc. it'll use direct download too because all these browsers (including IE9+) does not stop your download when you accidentially close your visiting page. Only IE8 or below have a problem on that.
For a record, last night I get 1400+ kb/s with File Transfer Manager. (Is it kb or kB? I can't remember but it's whatever speed show on the dialog)
So it's clearly related to your network performance. It's not only affected by raw network speed, but also how many users are using the same gateway to load large files, and how your ISP defines the route to MSDN download center. etc. (Some ISPs set special route to high profile speed test sites so you can always get a better-than-it-should result there. A little bit tracert (traceroute) will reveal this trick if applied)
Let's see if there will be other PCL libraries in VS Next.
Btw, is that possible to sell libraries that runs on iOS, that pre-submitted the code to Apple for review and therefore need not give source code to the people who bought it?
If iOS is to be supported, there must be an Objective C translator (unless if the new framework is based on Objective C, of course).
How they can get it implemented sounds very tricky to me, because performance has a real importance in gaming industry.
Yes, if that's the case change it to explicited compile as "x86" should fix it.
I've run into similar issue. A.exe calls B.dll and C.dll, and B.dll which calls C.dll. Both A.exe and B.dll are .NET assemblies compiled for "Any CPU", C.dll is native 32-bit library, but D.dll is native 64-bit runtime. In such case, when the code runs B.dll becomes 32-bit process, BadImageFormatException is thown when it runs D.dll later. I do exactly this step to fix the problem.
If you suspect it's because of this issue, check to see if BadImageFormatException is thrown.