none
Is There a 64-Bit Access Calendar Control that can import a 32-bit calendar? RRS feed

  • Question

  • Hello:

    I have an application that requires a 64-bit calendar control for Access 365, but it needs to be able to import a 32-bit calendar control.  Is there such an entity?

    I have seen various user-written 64-bit calendar controls, but they must be able to import the 32-bit calendars.

    Thanks,


    Rich Locus, Logicwurks, LLC

    http://www.logicwurks.com

    Sunday, November 22, 2020 1:21 AM

Answers

  • Suggest you instead use a non ActiveX control so that it will work in both 32-bit & 64-bit Access.

    For example, see my Better Date Picker. If that's not what you want, there are numerous others available

    • Marked as answer by RichLocus Monday, November 23, 2020 4:15 AM
    Sunday, November 22, 2020 8:20 AM
  • The decision to jump and switch from x32 bits to x64 bits is a BIG decision, and requires a LARGE amount of planning and testing.

    While the jump from say windows 3.1 to Windows 95 (16 bits to x32 bits) was painful? Well, most 16 bit software (from windows 3.1) would run fine on x32 bits.

    However, it still was a huge jump, and that jump requires significant testing and planning on your part.

    For example, jumping from Office x32 to x64 bits?

    Well, any ActiveX controls? Most vendors don’t have x64 bit versions of such controls. This includes the calendar control.

    And keep in mind the last version of Access to ship with the ActiveX control was Access 2003. So, we talking about a 17 year old software component. (Only you can decide how many software systems you are currently installing and running are that old – but it is VERY old).

    Also, keep in mind that QuickBooks, Sage 50 (formerly Simply accounting), and Sage 300 (formally Acc-pac) all do NOT have x64 bit versions of their software. That means if your office programs such as Excel or say Access directly interact with these accounting programs? Well, then you can’t adopt office x64 bits. 

    The same goes for any other software systems you may have adopted over the years. So a lot of office add-ins, interaction with accounting packages, outlook add-ins?

    You jump to x64 bits, then all those accounting systems, and add-ins will now not work.

    So, just like the jump from say an Apple II to 16 bit DOS and the IBM XT was big jump? 

    You are in the same boat. And this also means that any windows API calls you have in Access/VBA also have to be changed.

    The same goes for the calendar control. There is not an x64 bit version right now.

    So, there is no drop in replacement.

    This suggests you want to find/adopt a replacement that is CLOSE to the code and use of the ActiveX one.

    As you note, there are quite a few alternatives, but MOST were not written with replacement of the ActiveX in mind. Well, ok, they were no doubt written out of desperation, but the goal, the idea, the concept should be that the replacement should be as close as possible from a VBA coding point of view.


    So you can no more run that Apple II 8 bit software on that new computer. And it quite much goes the same for running 16 bit windows 3.1 software on a brand new windows box.

    And same goes for your case. You are adopting a new x64 bit architecture for office.

    So, this is a big deal and big jump.

    I currently still have and force customers to stick to x32 bit installs of office. However, we are seeing MORE and more sites now attempting to install x64 bit office. However, for companies that been using office for a long time? Well, any ActiveX, or even things like interactions with accounting packages has to be taken into consideration.

    I don’t know how far you are into this transition, nor is say your IT department, but significant resources, time and planning is required for such a huge architecture change here.

    I’m somewhat busy today (doing some Android software), but I can and will post my Access calendar replacement here if you wish.

    It looks quite similar to the old one, and the changes to your VBA code are quite minimal.

    Just keep in mind, that Access 2007 (and all the way up to 2019) will display a calendar selector automatic for any date field you have on a form. This is great for say any date field on a form, but for a nice “larger” start end date prompt, then it not all that great.

    So, for date fields on a form? Then I would go with (adopt) and use the built in date picker that access now has.

    Only say for a larger date calendar picker on a form is when I would consider adopting a replacement. So, depending on your needs and how/when/where/what goal your needs are will MUCH determine how badly and how much effort you want to expend on this issue.

    Regardless of having no x64 bit ActiveX calendar control? This will take a good deal of planning and cooperation from your IT departments, since you not just upgrading office, but jumping to x64 bit architecture – and that means this is quite much the same challenge as jumping from windows 3.1 to windows 95, or jumping from an older 8 bit computer say to DOS running on a new PC.

    So, don’t know how far you are into your planning stages, and the change of a bit size architecture – but planning is required for this transition to a new x64 bit architecture for Office.

    In fact, I not sure I would use the ActiveX control if there was one!! – the reason being it is now 17 years old. So, we talking about Access 2003 days from 17 years ago!

    However, it is a good ideal to start on your adventure quest now, since over time, no doubt the future holds that most of the software we will run will in fact be x64 bits.

    I do suggest you make a clear distinction between a form with date fields (and the calendar is NOT visible), but when they edit a date field, the pop calendar is desired. This is supported in new Access versions, and in fact is automatic.

    However, in the few cases in which you need say a calendar ALWAYS in display? That's when the suggested replacements (often written in VBA) are a good choice.

    Regards,
    Albert D. Kallal (Access MVP 2003-2017)
    Edmonton, Alberta Canada

    • Marked as answer by RichLocus Monday, November 23, 2020 4:15 AM
    Sunday, November 22, 2020 8:52 PM

All replies

  • Suggest you instead use a non ActiveX control so that it will work in both 32-bit & 64-bit Access.

    For example, see my Better Date Picker. If that's not what you want, there are numerous others available

    • Marked as answer by RichLocus Monday, November 23, 2020 4:15 AM
    Sunday, November 22, 2020 8:20 AM
  • The decision to jump and switch from x32 bits to x64 bits is a BIG decision, and requires a LARGE amount of planning and testing.

    While the jump from say windows 3.1 to Windows 95 (16 bits to x32 bits) was painful? Well, most 16 bit software (from windows 3.1) would run fine on x32 bits.

    However, it still was a huge jump, and that jump requires significant testing and planning on your part.

    For example, jumping from Office x32 to x64 bits?

    Well, any ActiveX controls? Most vendors don’t have x64 bit versions of such controls. This includes the calendar control.

    And keep in mind the last version of Access to ship with the ActiveX control was Access 2003. So, we talking about a 17 year old software component. (Only you can decide how many software systems you are currently installing and running are that old – but it is VERY old).

    Also, keep in mind that QuickBooks, Sage 50 (formerly Simply accounting), and Sage 300 (formally Acc-pac) all do NOT have x64 bit versions of their software. That means if your office programs such as Excel or say Access directly interact with these accounting programs? Well, then you can’t adopt office x64 bits. 

    The same goes for any other software systems you may have adopted over the years. So a lot of office add-ins, interaction with accounting packages, outlook add-ins?

    You jump to x64 bits, then all those accounting systems, and add-ins will now not work.

    So, just like the jump from say an Apple II to 16 bit DOS and the IBM XT was big jump? 

    You are in the same boat. And this also means that any windows API calls you have in Access/VBA also have to be changed.

    The same goes for the calendar control. There is not an x64 bit version right now.

    So, there is no drop in replacement.

    This suggests you want to find/adopt a replacement that is CLOSE to the code and use of the ActiveX one.

    As you note, there are quite a few alternatives, but MOST were not written with replacement of the ActiveX in mind. Well, ok, they were no doubt written out of desperation, but the goal, the idea, the concept should be that the replacement should be as close as possible from a VBA coding point of view.


    So you can no more run that Apple II 8 bit software on that new computer. And it quite much goes the same for running 16 bit windows 3.1 software on a brand new windows box.

    And same goes for your case. You are adopting a new x64 bit architecture for office.

    So, this is a big deal and big jump.

    I currently still have and force customers to stick to x32 bit installs of office. However, we are seeing MORE and more sites now attempting to install x64 bit office. However, for companies that been using office for a long time? Well, any ActiveX, or even things like interactions with accounting packages has to be taken into consideration.

    I don’t know how far you are into this transition, nor is say your IT department, but significant resources, time and planning is required for such a huge architecture change here.

    I’m somewhat busy today (doing some Android software), but I can and will post my Access calendar replacement here if you wish.

    It looks quite similar to the old one, and the changes to your VBA code are quite minimal.

    Just keep in mind, that Access 2007 (and all the way up to 2019) will display a calendar selector automatic for any date field you have on a form. This is great for say any date field on a form, but for a nice “larger” start end date prompt, then it not all that great.

    So, for date fields on a form? Then I would go with (adopt) and use the built in date picker that access now has.

    Only say for a larger date calendar picker on a form is when I would consider adopting a replacement. So, depending on your needs and how/when/where/what goal your needs are will MUCH determine how badly and how much effort you want to expend on this issue.

    Regardless of having no x64 bit ActiveX calendar control? This will take a good deal of planning and cooperation from your IT departments, since you not just upgrading office, but jumping to x64 bit architecture – and that means this is quite much the same challenge as jumping from windows 3.1 to windows 95, or jumping from an older 8 bit computer say to DOS running on a new PC.

    So, don’t know how far you are into your planning stages, and the change of a bit size architecture – but planning is required for this transition to a new x64 bit architecture for Office.

    In fact, I not sure I would use the ActiveX control if there was one!! – the reason being it is now 17 years old. So, we talking about Access 2003 days from 17 years ago!

    However, it is a good ideal to start on your adventure quest now, since over time, no doubt the future holds that most of the software we will run will in fact be x64 bits.

    I do suggest you make a clear distinction between a form with date fields (and the calendar is NOT visible), but when they edit a date field, the pop calendar is desired. This is supported in new Access versions, and in fact is automatic.

    However, in the few cases in which you need say a calendar ALWAYS in display? That's when the suggested replacements (often written in VBA) are a good choice.

    Regards,
    Albert D. Kallal (Access MVP 2003-2017)
    Edmonton, Alberta Canada

    • Marked as answer by RichLocus Monday, November 23, 2020 4:15 AM
    Sunday, November 22, 2020 8:52 PM
  • Albert:

    Wow!  That was a thorough answer!!

    Rich


    Rich Locus, Logicwurks, LLC

    http://www.logicwurks.com

    Monday, November 23, 2020 4:15 AM