locked
Offce 2010 x64 edition ships with x86 mscomctl.ocx RRS feed

 , 
 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    The mscomctl.ocx file shipped with the x64 beta is an x86 DLL.  We want to move our applications (which include a tremendous amount of C++ code and VBA in Office) to the x64 version of Office 2010.  We have most everything completed, but have noted that the mscomctl.ocx shipped with the x64 beta is an x86 DLL.  It is stored in the C:\Windows\System32 folder (not the C:\Windows\SYSWOW64 folder), but it indeed is an x86 build as confirmed by dumpbin.

    Is this going to be changed for the final release?  The x86 version will not load in the x64 version.  There will be a lot of VBA code out there that will not be compatible with the x64 version if these controls are not changed to support x64.

    Thanks.
    • Moved by Alicia CalesMicrosoft employee Wednesday, April 28, 2010 9:42 PM Forums Consolidation (From:Microsoft Office 2010 Application Compatibility)
    Thursday, February 25, 2010 6:30 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    If you don't support mscomctl.ocx for both the x86 and x64 platforms, what are the options to migrate VBA applications that depend upon them to the new version of Office?  I don't think VSTO is an alternative as much of our work is code for Visio in addition to Word and Excel.  Visio is not supported by VSTO is it?  Even if it is, realize that many of our customers will be running Visio 2003, 2007, and eventually 2010.  Is there a way to handle all of these versions?
    Wednesday, March 3, 2010 4:15 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    It was a bug that we included the 32-bit version of ComCtl in the 64-bit version of Office 2010 at beta. That has been corrected for the final release, by no longer installing any version of ComCtl with 64-bit Office 2010. Which doesn't address your real need: a 64-bit version of ComCtl. We are continuing to evaluate the customer need for this, and your post helps us to prioritize this work. I would ask one question - which controls out of the ComCtl collection do you use? If there are others out there that have a need for a 64-bit version of ComCtl, please post your request here or send email to gregli@microsoft.com. Please include specifics of how you use ComCtl, in particular which of the controls are most important. Thanks, Greg
    Thursday, February 25, 2010 10:28 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I'll get you a list, but it's going to be a major effort if this is not supported.  So much of an effort that I'm offering to get your common controls working in 64 bit without charge.  Even would sign an NDA.

    The situation now is different than when x64 OSes were strictly for servers.  With desktop applications, you expect these types of controls to be present to assist us in migrating the wide variety of desktop applications to x64.  I suspect many applications will have to stay as x86 without this and similar support (and that may be a problem as well without the x86 version).  However, we would like our product to be x64 native for many reasons as our application is much larger and more complex than typical applications.

    For us it is not strictly VBA code.  We have well over 10,000 files of C++ source code that serve as addins to Visio, Excel and Word.  It all has to be migrated for everything to work.  We're very close except for the ActiveX controls for mscomctl.ocx and msscript.ocx.
    Friday, February 26, 2010 1:35 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Greg:

    We are using the following controls in mscomctl.ocx:

    ListView (with ListItem & ListSubItem), ImageList (with ListImage), TreeView (with Nodes) and ProgressBar
    Friday, February 26, 2010 5:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    If you don't support mscomctl.ocx for both the x86 and x64 platforms, what are the options to migrate VBA applications that depend upon them to the new version of Office?  I don't think VSTO is an alternative as much of our work is code for Visio in addition to Word and Excel.  Visio is not supported by VSTO is it?  Even if it is, realize that many of our customers will be running Visio 2003, 2007, and eventually 2010.  Is there a way to handle all of these versions?
    Wednesday, March 3, 2010 4:15 PM
  • Question
    Sign in to vote
    3
    Sign in to vote

    Since being labeled "common controls" we expected them being available for ever ...

    Common Controls like ListView excel VBA's Listbox simply by having an included header, ability of being sorted and simplicity of being programmed. Not to mention the possibility to display icons. Controls like TreeView are not possible with pure VBA but handy and required - otherwise you would not have included them in your "Common Controls". ImageList is required as supporter for both controls.

    Other controls are not that important - i.e. ProgressBar, which is just nice to look at but can be substituted by displaying progress within StatusBar and changing Mouse Cursor to Wait (not that nice but works) - or were replaced by pure API solutions thanks to some enthusiastic developers - i.e. DateTimePicker Ctrl which has been published as VBA solution using Windows API for MS Access some years ago.

    Thinking about the DateTimePicker Ctrl brings me to the point where I am getting concerned - this solution was developed because custom solutions could not be distributed because MS restricted using the relevant control. The guys developing the workaround spend ~3 years developing it - ~3 years they could have spend developing real solutions - real solutions based on your applications.

    In my opinion, discussing whether to publish "Common Controls" for 64bit or not, or perhaps a little bit of it but not all, is ridiculous. We chose developing on MS platform because we believed that will give our solutions a long lasting platform to work on. If I was aware I would have to build the platform myself, too, I could have choosen Open Office to develop on. OK, not 100% fair, but you might have gotten the idea.

    Not supporting "Common Controls" for 64bit will mean a lot of extra work for every serious developer. Whether this means creating own controls or switching to VSTO solutions - it is simply not fair. A customer simply will not be willing paying for the extra efforts - leaving the developer with the costs or forcing a totally different approach. Such a different approach means extra costs, too, which leads to the same conclusion: the developer is f****.

    Of course you might say VBA is outdated and will be dismissed, soon. Developers shall use VSTO (or .Net solely) for developing applications. You might state, VBA is no longer supported and it even does not work anymore. But then say so. Clearly. Being "a little bit pregnant" does not work.

    Summary: In order to continue a reliable software evolution process MS has to port "Common Controls" to 64bit. And if to wipe out VBA, say it clearly, giving time to port the existing solutions.

    Thanks; UG

    Tuesday, June 8, 2010 5:14 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Absolutely agree with UG.

    I have clients that have upgraded to Office 2010 as its just been announced, and was immediately notified that all our custom built apps don't work. We used the Listview control extensively as it made it easy to display information, whilst giving us security knowing it was a 'Common Control'. It was always going to work. 

    Please help your target developers out here! We need a solution to this otherwise it will invalidate years of development. 

    sfoxe

    Monday, June 14, 2010 12:21 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I suspect that as more and more people attempt to use x64, they will find out about this limitation and likely will not upgrade or use x64 Office due to the effort involved in the migration.

    With my C++ experience, I'd be willing to bet a signifncant amount of money that I could get the controls working in x64 in less than a week.  That's one man week's effort versus no telling how many man years will be expended trying to rewrite working code.

    Tuesday, June 15, 2010 1:36 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    We would need that ocx too. Imagelist and treeview are the controls we use in Excel forms. I agree with sfoxe that it would save us a lot of work if you could provide this control for the new 64bit version.

    Another issue:  I was shocked when I realized that we had to update all our declares. I think Microsoft should rethink this. VBA is a parsed language. It should be possible to resolve 32 / 64 bit issues in the background. I seem to remember that this was the case when we moved from 16 / 32 bit office.

    Jörg

    Tuesday, July 20, 2010 11:04 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I am also still having this issue, I have a program (2100+ lines) That has the progress, status bar, and treeview littered through it and used nearly everywhere possible for user feedback and am currently having to bascally split my program now into a X86 and X64 version and basically go into the 64b version and comment out everysingle place i use those three controls... Any word on this!?
    Monday, August 9, 2010 1:37 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I think Microsoft has said they could care less.  I wish we had only 2100 lines of code.

    • Proposed as answer by Chris Issy Sunday, August 15, 2010 6:38 PM
    • Unproposed as answer by David Wolters Monday, January 30, 2012 4:32 PM
    Monday, August 9, 2010 1:47 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have had the same kind of issue.

    Try the following:

    1. unselect "MSCOMCTL.OCX" file from "tools\references" VBA menu option
    2. close / reopen tool window
    3. reselect file "MSCOMCTL.OCX"
    4. recompile

    For me, it was ok

     

    HTH

    Regards

    Sunday, August 15, 2010 6:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Chris:

    There is no workaround.  I think you're misunderstanding the issue.

    Sunday, August 15, 2010 11:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Anything new on this? It's now December.

    I, too, am dead in the water with regard to upgrading my clients to 64bit Word. They depend upon a document assembly addin product that extensively uses the Tree View of mscomctl, and they are not willing to forgo their addin program just to go to Word2010, (While in one sense it makes me feel good since I also authored the add-in, I think they would benefit from what the Word 64bit can do for them.)

    I reiterate the call for a 64bit version of ComCtrl. (How hard could it be for MS to do this for its many loyal customer and programmers????)

    Thursday, December 16, 2010 9:49 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Greg, I posted elsewhere on this board, but I don't know if you monitor it constantly. Please advise on mscomctl status for 64 bit. Thanks. I badly need TreeView and ListView.
    Thursday, December 16, 2010 9:52 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Simdoc -- you mentioned the possibility of creating a comctr for 64 bit. Did you ever create one and are you marketing it> I, for one, would be willing to buy a license from you.

    Roy Lasris
    Thursday, December 16, 2010 9:58 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    one more, who is urgently looking for Listview, Progressbar & Co.

    Does anybody has any feedback of microsoft?

    Stefan

    Stefan Sohst SOHST DATA Vertriebssoftware und individuelle Office-Programmierungen
    Tuesday, February 22, 2011 2:29 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I opened a support case with MS several months ago on this.  They told me it is not going to happen--period.  It did not sound like there would be any possibility of changing their position.
    Tuesday, February 22, 2011 2:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Assuming that Simdoc is correct and MS is going to screw everybody similarly situated, there still has got to be a workaround. I have been hunting for months to find the alternative that MS says we must seek on our own, but I'll be darned if anything has popped up.

    So, let's turn this more pro-active and positive. The fact that this thread has been reactivated may be the turning point.

    Does anyone out there know of a solution to providing TreeViews in 64 bit Word? If so how is it done?

    Absent a current solution, does anyone out there have the skills to write a tool that can be popped into a VBA project to provide a TreeView. I will be pleased to pay for the tool, as I am sure others similarly situated would be.

    (Please answer to this thrread only if (1) you have a solution, or (2) you need the solution and are willing to pay for a fair share of its develpment costs so as to give a development incentive to a potential author.)

    Roy Lasris
    Tuesday, February 22, 2011 3:06 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    You can look at http://msdn.microsoft.com/en-us/vbasic/bb419144.aspx.  But be aware, the changes required are significant.  We haven't decided if we're going to use that approach or write our own control in C++ to replace the Microsoft control.  We have a large amount of code that needs to be changed.

    Either approach will require us to waste a large amount of time and money that could easily be saved if MS distributed the control.  As someone with an extensive Windows programming background, I promise it will cost just our organization much more to make changes than it would cost MS to migrate the control to x64.  No telling what the total cost will be for everyone to make the changes.

    I suspect this will prevent many end-users from going to x64 for Office because they will find many of their addins will not function because of this limitation.

    Tuesday, February 22, 2011 8:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It seems that if Microsoft is not going to re-compile these controls into 64-bit, they could at least make the code available so that others

    can do it. 

    Friday, February 25, 2011 5:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yes we also need 64-bit version of ComCtl, otherwise we cannot upgrade to 64-bit Office 2010.  ipso facto.

    Thursday, April 14, 2011 7:37 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I just ran accross this thread while researching this same issue. Anyone found an updated control yet. If not I echo the call for one from Microsoft.

    Friday, May 13, 2011 7:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Any progress on this issue?  We also have applications developed for Excel which originally used the date picker MSCAL.ocx.  We can change that to use the date picker in the Mscomct2.ocx, but that does not help with 64 bit Office 2010 installations.

     

    • Proposed as answer by GaryArnold Friday, January 13, 2012 6:10 AM
    Tuesday, July 5, 2011 3:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have a VBA app that was using MSCAL.ocx.  I was not able to find a good solution for my 64 bit clients so I made my own VBA calendar control as a VBA form.

    I'll post it on my web site at ssitools.com under Software/Free Downloads

    Friday, January 13, 2012 6:11 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks Gary for the help. It seems this thread has died. MSFT continues to screw its customers. 
    Monday, January 30, 2012 11:58 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I still say x64 Office will never be a major commercial platform without this compatibility.  Everyone is going to find out that their addins are going to fail.  You may find use in small organizations and academia, but not in large corporations where addins are prevalent.

    No one wants to rewrite everything they've done in the past.  We wrote our own replacement controls, and spent significant time in doing it.  It was easier to do that, than to redesign our application to use VSTO.  Further, I'm not certain VSTO would give us what we need anyway.

    Monday, January 30, 2012 2:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello simdoc,

    You said you have written replacement controls for the treeview, etc..

    Would it be possible to share this with the community? That would be great, as many people try to migrate their projects to 64 bit.

    Thanx Excattala

    Tuesday, February 7, 2012 9:37 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    That's owned by the company I work for and they won't let me share them.
    Tuesday, February 7, 2012 1:53 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I will add to the list of those needing a solution. 

    Steve

    Wednesday, February 15, 2012 7:51 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    We also very much need a 64-bit version of mscomctl. We use Listview, Treeview, ProgressBar, Imagelist, ToolbarControl. It would cost us months to convert (rebuild) everything into .NET DLLs or VSTO.

    Microsoft could also kill the 64-bit Office version (you don't need it anyway), so our customers cannot make a mistake they cannot grasp. And why do IT-departments think 64-bit office is needed (mandatory) on a 64-bit windows??

    Ronald

    Saturday, March 31, 2012 7:34 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    We are in the same situation : loose MSCOMCTL.OCX for Office 64 bits will destroy our business in next years !!! We have based most of functionalities of our software (http://cd-concept.com) on Treeview and Imagelist supplied by MSCOMCTL library. I totally agree with UG408715 for his description of the problem and WGaskill for

    Is there now any issue about those crazy news ? Is anybody wrote to gregli@microsoft.com that is mentioned at the beginning of this thread ? Thanks for help.

    Sami.


    Wednesday, April 18, 2012 9:32 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    We have a lot of staff written in vba for excel and word. And that prevents us from using x64 versions of MS Ofiice...
    Tuesday, April 24, 2012 6:00 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Is aynone At Microsoft paying attention to this issue? There are some questions i have:

    How is it possible that Microsoft has, on a totally irresponsible an unilateral way, decided it is not going to support its common controls in 64 bit office? Who is the idiot who decided this? What explanation does he/she has to justify this?

    Does anyone at Microsoft realize all the man-years invested on building applications using these controls?

    What does Microsoft expect us developers to do with these applications? ¿Simply rebuild them? or maybe we should move them to a non-microsoft platform?

    Is Microsoft aware of what the words "customer", "support" or "loyalty" mean?

    Is anyone at Microsoft going to show his/her face and give a satisfactory answer to us?

    Monday, June 25, 2012 2:47 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    They stopped paying attention to it the day I started the thread--actually before that.
    Monday, June 25, 2012 1:23 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I cannot believe Microsoft think that they can unilaterally decide this. I pay vast sums of money for their products. I then design and build VBA solutions for clients who also spend vast sums of money on MS products.

    Now, their products do not work, there is nothing I can do about it - and MS continue to take money. WE ARE YOUR CLIENTS. You are putting people out of business here, it would take you days to sort this out, I accept you don't seem to like VBA anymore (which is naive) - but stop screwing us over

    Saturday, September 8, 2012 9:40 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The worst thing about it, I think the effort would be minimal.  We have significant experience developing these types of ActiveX controls in C++ and I suspect converting it to an x64 version would take less than a week's effort from an experienced developer.  They simply don't want to support it.

    Of course, no company of any size is going to move to x64 Office for a long time.  How can they?  They almost certainly have many of these addins for a variety of business uses that will not be compatible with x64 Office.

    Has anyone looked at the x64 version of 2013 to determine if it's there?  I was going to do that but haven't had time yet.

    Saturday, September 8, 2012 2:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I haven't looked at 2013, but I'm pretty confident it won't be 

    It seems to me that it is not about the effort, it's about the principal. I think MS have decided to kill off VBA, and what better way to do it than to not allow anything other than basic controls on userforms. We will have to go to VSTO to build more complex forms.. .I don't mind change, I don't mind VSTO but they have some kind of responsibility in my mind to be backwards compatible and I don't see how x64 Office can be called backwards compatible given this issue.

    Sunday, September 9, 2012 8:13 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I agree it's about principal.  I'm saying with minimal effort they could maintain backwards compatibility. They don't have to make future enhancements.  But they don't have to kill it either.

    Sunday, September 9, 2012 3:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I've raised a support ticket about it, but I'm not holding my breath.
    Sunday, September 9, 2012 4:47 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    So I sent them a mail explaining very clearly the problem, and this is the reply I got, concerning activating my product:

    Dear James,<o:p></o:p>

     <o:p></o:p>

    You
    have reached Microsoft Customer Service, South East Asia. My name is
    Jaclyn and I would address your Office 2010 inquiry. As I understand it,
    you are having some technical issue with Office 2010. If my
    understanding is inaccurate, please let me know. <o:p></o:p>

     <o:p></o:p>

    For
    this information Please be kindly informed that you would have to call
    your local Microsoft Customer Service Representative who could activate
    the product for you. Kindly check the phone number from the link below;<o:p></o:p>

     <o:p></o:p>

    http://www.microsoft.com/worldwide   ;   select your country <o:p></o:p>

     <o:p></o:p>

    Sincerely,
    it was a pleasure helping you.  If ever you need further assistance
    please don’t hesitate to send us an email and we will be more than happy
    to help you.<o:p></o:p>

     <o:p></o:p>

    Thank you for contacting Microsoft. Have a nice day!<o:p></o:p>

     <o:p></o:p>

    Regards, <o:p></o:p>

    Jaclyn<o:p></o:p>

    Customer Service Representative <o:p></o:p>

    Microsoft Customer Service, South East Asia (SEA)

    Monday, September 10, 2012 7:19 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello everybody,

    I just found this thread as it fits perfectly to my problem, too.

    The answer jpadlimited was given is very funny - if the problem would not be a showstopper for someone to do his/her job and earn money.

    As it turns out, "common controls" are only controls and not essential. (well not for MS)

    In 2010 UG described perfectly in what trouble we are all in.

    I don't know if MS is aware about the real strength of their products. It's not the functions implemented by them but the powerful programming language which empowers many people to develop best fitting functions for customers.

    Why don't they project Steve Ballmers "Developers, developers, developers, ..." to those many third party developers in the world.

    And: it's not only the mscomctl but comctl32 ...

    Hopefully waiting for the Office 2010 Update 1

    Stefan

    Tuesday, September 18, 2012 12:29 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    i found a fix for this in my case

    i have a 64 bit PC but office is 32 bit version

    the mscomctl.ocx is there and registered under the syswow -

    ...but controls (treeview) was not registering events ..

    fix for us was:

    got 32 bit - 'mscomctl.ocx' and dropped in 'C:\windows\System32\mscomctl.ocx'

    then in command run

    regsvr32 'C:\windows\system32\mscomctl.ocx'

    • Proposed as answer by KennethEGski Monday, November 19, 2012 5:34 PM
    Monday, November 19, 2012 5:34 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Anyone found a solution for this problem? Or have we just given up to a higher power?

    I agree with you, MS doesn't realize the problem their putting us into.

    Tuesday, June 25, 2013 9:15 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Nearly 4 years on, an new version of Office released, a different way of delivering Office through 365, yet still no simple fix for this issue!

    Microsoft, what exactly is the problem in releasing the source code of the controls? As far as I understand it, Microsoft now play a very active part in the Open Source communality such as with development to the Linux Kernel - why not offer these controls to your users to recompile them for 64 bit systems for you? What is the business risk to you?

    Chris

    Tuesday, December 24, 2013 7:50 PM