Sorry, I don't really understand your point. I realise VSTO will be the way to go, I don't really have many issues with that. My point is that I pay MS a lot of money, as do my clients. Solutions have been built in good faith that MS will maintain backwards compatibility, and they are effectively costing myself, and my clients a lot of money - to redevelop solutions, because they don't want to make their new products wholly backwards compatible. I consider that irresponsible and pretty bad in terms of customer service. What argument is there for not making it backwards compatible so existing solutions continue to work? to force all devlopers and clients to buy Visual Studio and redevelop all their existing VBA solutions? Is that not some kind of con?
On Sunday, 9 September 2012 14:44:51 UTC+1, bpascal123 wrote: > At some point, developing for Office requires access to Visual Studio full > package or alternative equivalent tools. I don't think it's about killing > VBA for VSTO, I would see this more like setting or defining a border > between Office custom solution and Office professional solution. It makes > sense, MS wants to keep a hand on major widely used products. > To me, as I can't access Visual Studio or other equivalent application for > developers, I would look for open source solutions where I can implement a > solution that can access system resources and properties... > > On Saturday, September 8, 2012 10:27:24 AM UTC+1, james D wrote: >> >> I think MScomt2 is a version of mscomctl, not really sure. >> >> Seems we're all agreed things won't work in 64 bit office. Which is not >> great for developers. It would take MS days to sort this out, as opposed to >> developers and clients spending months sorting it out - not to mention us >> developers who will inevitably end up with soured client relationships due >> to this. >> >> Feels like MS are trying to kill VBA for VSTO. Fine, I'm sure everyone >> will follow suit, but why screw everyone over in the process? >> >> >> On Friday, 7 September 2012 17:38:42 UTC+1, james D wrote: >> >>> Hi. >>> >>> I am a VBA developer (Excel mainly) - I have built an Excel dashboard >>> which contains a userform with a treeview on it. It all works fine pre >>> Windows 7 with Office 2010, but with Windows 7 (and Office 2010) the >>> treeview is no longer visible on the form. >>> >>> I have been searching most of the day. I have a registered (as admin) >>> version of mscomctl.ocx in sysWOW64 - still nothing... can anyone help? >>> >>> When I add a reference to mscomctl in Tools/references, then choose >>> additional controls via the toolbox treeview is not in the list... is it >>> supposed to be in mscomctl? >>> >>> >>> Thanks, >>> James >>> >>> NB: This isn't an issue just on my machine, several others have the same >>> issue. >>> >> -- Join official facebook page of this forum @ https://www.facebook.com/discussexcel FORUM RULES (1120+ members already BANNED for violation) 1) Use concise, accurate thread titles. Poor thread titles, like Please Help, Urgent, Need Help, Formula Problem, Code Problem, and Need Advice will not get quick attention or may not be answered. 2) Don't post a question in the thread of another member. 3) Don't post questions regarding breaking or bypassing any security measure. 4) Acknowledge the responses you receive, good or bad. 5) Cross-promotion of, or links to, forums competitive to this forum in signatures are prohibited. 6) Jobs posting is not allowed. 7) Sharing copyrighted ebooks/pirated ebooks/their links is not allowed. NOTE : Don't ever post personal or confidential data in a workbook. Forum owners and members are not responsible for any loss. --- You received this message because you are subscribed to the Google Groups "MS EXCEL AND VBA MACROS" group. To post to this group, send email to excel-macros@googlegroups.com. To unsubscribe from this group, send email to excel-macros+unsubscr...@googlegroups.com.
