I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
(And let's face it...we VFP devs need all the marketing hype we can get if we're still pushing our apps. lol)
On 4/16/2020 11:28 AM, MB Software Solutions, LLC wrote:
I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
I can't recall if what was patched in that VFP "10" also addressed things like max array sizes, max text strings, size of 'index data' loaded into memory, etc. In general, things might just simply run faster (under the hood stuff of running 32-bit on 64-bit). And maybe the 'modern' ODBC drivers (64-bit) can now be used? <shrug>
Probably the best answer would be to try to recompile an app into VFP 10 and do some speed/timing tests (like anyone has time for that.... heh).
-Charlie
On Thu, Apr 16, 2020 at 12:32 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
(And let's face it...we VFP devs need all the marketing hype we can get if we're still pushing our apps. lol)
On 4/16/2020 11:28 AM, MB Software Solutions, LLC wrote:
I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Chen's documentation on what's been done should have those answers. One thing definitely not done is the 2GB single file size limit.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Charlie Coleman Sent: Thursday, April 16, 2020 12:50 PM To: profoxtech@leafe.com Subject: Re: 64-bit app via the Chen version
I can't recall if what was patched in that VFP "10" also addressed things like max array sizes, max text strings, size of 'index data' loaded into memory, etc. In general, things might just simply run faster (under the hood stuff of running 32-bit on 64-bit). And maybe the 'modern' ODBC drivers (64-bit) can now be used? <shrug>
Probably the best answer would be to try to recompile an app into VFP 10 and do some speed/timing tests (like anyone has time for that.... heh).
-Charlie
On Thu, Apr 16, 2020 at 12:32 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
(And let's face it...we VFP devs need all the marketing hype we can get if we're still pushing our apps. lol)
On 4/16/2020 11:28 AM, MB Software Solutions, LLC wrote:
I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Yes, but the 2GB ceiling doesn't apply in my case since I'm using MariaDB/MySQL.
We've got some folks here using the VFPA (10) IDE and deploying their EXEs with the updated VC++ 10 runtime, don't we?
Alan? wOOdy? Tracy?
On 4/16/2020 12:59 PM, Richard Kaye wrote:
Chen's documentation on what's been done should have those answers. One thing definitely not done is the 2GB single file size limit.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Charlie Coleman Sent: Thursday, April 16, 2020 12:50 PM To: profoxtech@leafe.com Subject: Re: 64-bit app via the Chen version
I can't recall if what was patched in that VFP "10" also addressed things like max array sizes, max text strings, size of 'index data' loaded into memory, etc. In general, things might just simply run faster (under the hood stuff of running 32-bit on 64-bit). And maybe the 'modern' ODBC drivers (64-bit) can now be used? <shrug>
Probably the best answer would be to try to recompile an app into VFP 10 and do some speed/timing tests (like anyone has time for that.... heh).
-Charlie
On Thu, Apr 16, 2020 at 12:32 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
(And let's face it...we VFP devs need all the marketing hype we can get if we're still pushing our apps. lol)
On 4/16/2020 11:28 AM, MB Software Solutions, LLC wrote:
I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Not I.
I haven't been able to make the time for it to happen. There's a lot of testing that needs to be done before I can ship a new runtime.
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Thursday, April 16, 2020 1:29 PM To: profoxtech@leafe.com Subject: Re: 64-bit app via the Chen version
Yes, but the 2GB ceiling doesn't apply in my case since I'm using MariaDB/MySQL.
We've got some folks here using the VFPA (10) IDE and deploying their EXEs with the updated VC++ 10 runtime, don't we?
Alan? wOOdy? Tracy?
On 4/16/2020 12:59 PM, Richard Kaye wrote:
Chen's documentation on what's been done should have those answers. One thing definitely not done is the 2GB single file size limit.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Charlie Coleman Sent: Thursday, April 16, 2020 12:50 PM To: profoxtech@leafe.com Subject: Re: 64-bit app via the Chen version
I can't recall if what was patched in that VFP "10" also addressed things like max array sizes, max text strings, size of 'index data' loaded into memory, etc. In general, things might just simply run faster (under the hood stuff of running 32-bit on 64-bit). And maybe the 'modern' ODBC drivers (64-bit) can now be used? <shrug>
Probably the best answer would be to try to recompile an app into VFP 10 and do some speed/timing tests (like anyone has time for that.... heh).
-Charlie
On Thu, Apr 16, 2020 at 12:32 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
(And let's face it...we VFP devs need all the marketing hype we can get if we're still pushing our apps. lol)
On 4/16/2020 11:28 AM, MB Software Solutions, LLC wrote:
I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
You are correct, there is no reason to have a 64bit FoxPro application for a regular Desktop app. It is different for building the middle-tier of a distributed app or a Webserver extension. But on a regular desktop you gain nothing, but inherit a lot of problems: No support for regular 32bit ActiveX or FLL components. No COM-control of Office or other 32Bit stuff.
Thus you better use the 32Bit version of VFPA, which is really highly recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software Solutions, LLC Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Ah yes, the automation angle. Temporarily forgot about that. Thanks, wOOdy!
On 4/16/2020 1:24 PM, Jürgen Wondzinski wrote:
You are correct, there is no reason to have a 64bit FoxPro application for a regular Desktop app. It is different for building the middle-tier of a distributed app or a Webserver extension. But on a regular desktop you gain nothing, but inherit a lot of problems: No support for regular 32bit ActiveX or FLL components. No COM-control of Office or other 32Bit stuff.
Thus you better use the 32Bit version of VFPA, which is really highly recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software Solutions, LLC Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Quick question. Are you all saying there is no Automation available to MS Office products in the 64-bit world?
I recently wrote a quick VFP app to 'automate' Outlook (ref: createobject('outlook.application')) to generate and send a bunch of emails. The Outlook 365 was 64-bit (I think). Are you saying I would not have been able to do that if I would have used the 'VFP 10' runtimes, etc? I understand ActiveX/FLLs that were compiled 32-bit would be an issue - if they did not have a 64-bit version included.
-Charlie
On Thu, Apr 16, 2020 at 1:30 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
Ah yes, the automation angle. Temporarily forgot about that. Thanks, wOOdy!
On 4/16/2020 1:24 PM, Jürgen Wondzinski wrote:
You are correct, there is no reason to have a 64bit FoxPro application
for a regular Desktop app. It is different for building the middle-tier of a distributed app or a Webserver extension. But on a regular desktop you gain nothing, but inherit a lot of problems: No support for regular 32bit ActiveX or FLL components. No COM-control of Office or other 32Bit stuff.
Thus you better use the 32Bit version of VFPA, which is really highly
recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software
Solutions, LLC
Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that
IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M
NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
(Renamed subject for this specific question for easier archive searching later in life...)
wOOdy -- Charlie had responded to your answer on my 64-bit thread. What do you think?
On 4/16/2020 2:50 PM, Charlie Coleman wrote:
Quick question. Are you all saying there is no Automation available to MS Office products in the 64-bit world?
I recently wrote a quick VFP app to 'automate' Outlook (ref: createobject('outlook.application')) to generate and send a bunch of emails. The Outlook 365 was 64-bit (I think). Are you saying I would not have been able to do that if I would have used the 'VFP 10' runtimes, etc? I understand ActiveX/FLLs that were compiled 32-bit would be an issue - if they did not have a 64-bit version included.
-Charlie
On Thu, Apr 16, 2020 at 1:30 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
Ah yes, the automation angle. Temporarily forgot about that. Thanks, wOOdy!
On 4/16/2020 1:24 PM, Jürgen Wondzinski wrote:
You are correct, there is no reason to have a 64bit FoxPro application
for a regular Desktop app. It is different for building the middle-tier of a distributed app or a Webserver extension. But on a regular desktop you gain nothing, but inherit a lot of problems: No support for regular 32bit ActiveX or FLL components. No COM-control of Office or other 32Bit stuff.
Thus you better use the 32Bit version of VFPA, which is really highly
recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software
Solutions, LLC
Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that
IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M
NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Yepp. No OLE-Automation from VFP x64 to any 32Bit product. And no admin would install the Office x64 version, since it even states in the setup, that you should use that x64 only if you have really, really, really big XLSX files etc. Bigger than 2 Gb. And it also states that Com/OLE problems.
https://support.office.com/en-us/article/choose-between-the-64-bit-or-32-bit...
You can check the version of your installed office somewhere under File / Options
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software Solutions, LLC Gesendet: Freitag, 17. April 2020 15:21 An: profox@leafe.com Betreff: Office automation using VFP 10 64-bit version
(Renamed subject for this specific question for easier archive searching later in life...)
wOOdy -- Charlie had responded to your answer on my 64-bit thread. What do you think?
On 4/16/2020 2:50 PM, Charlie Coleman wrote:
Quick question. Are you all saying there is no Automation available to MS Office products in the 64-bit world?
I recently wrote a quick VFP app to 'automate' Outlook (ref: createobject('outlook.application')) to generate and send a bunch of emails. The Outlook 365 was 64-bit (I think). Are you saying I would not have been able to do that if I would have used the 'VFP 10' runtimes, etc? I understand ActiveX/FLLs that were compiled 32-bit would be an issue - if they did not have a 64-bit version included.
-Charlie
On Thu, Apr 16, 2020 at 1:30 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
Ah yes, the automation angle. Temporarily forgot about that. Thanks, wOOdy!
On 4/16/2020 1:24 PM, Jürgen Wondzinski wrote:
You are correct, there is no reason to have a 64bit FoxPro application
for a regular Desktop app. It is different for building the middle-tier of a distributed app or a Webserver extension. But on a regular desktop you gain nothing, but inherit a lot of problems: No support for regular 32bit ActiveX or FLL components. No COM-control of Office or other 32Bit stuff.
Thus you better use the 32Bit version of VFPA, which is really highly
recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software
Solutions, LLC
Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that
IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M
NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
On Fri, Apr 17, 2020 at 2:22 PM Jürgen Wondzinski juergen@wondzinski.de wrote:
Yepp. No OLE-Automation from VFP x64 to any 32Bit product. And no admin would install the Office x64 version, since it even states in the setup, that you should use that x64 only if you have really, really, really big XLSX files etc. Bigger than 2 Gb. And it also states that Com/OLE problems.
I think you give "admins" too much credit, my friend. On many clients' new Windows 10 machines, I find Win10 64-bit, of course, and Office 64-bit. When challenged, I've been told that's the right one to install on 64-bit OSes. *eyeroll*
Of course, calling "the computer guy" they hired for the install-and-configure-gig on Craigslist an "admin" might be a stretch...
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
It's not helped by the fact that 64-bit Office will get installed by default now via Office 365, and you kind of have to jump through hoops to install the 32-bit version.
Not to beat this to utter death and disfigurement...
I definitely used Automation from 32-bit VFP into 64-bit Outlook. So are we saying that if I go to 64-bit VFP (the "VFP 10") that suddenly that same code would not work?
-Charlie
On Sat, Apr 18, 2020 at 6:37 AM Alan Bourke alanpbourke@fastmail.fm wrote:
It's not helped by the fact that 64-bit Office will get installed by default now via Office 365, and you kind of have to jump through hoops to install the 32-bit version.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
Are you absolutely sure that you have Office 64bit installed? Since it's not only me, but MS itself to state that it's technically impossible, I really doubt it. :) If yes, you would be the first to made it magically happen.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von Charlie Coleman Gesendet: Samstag, 18. April 2020 18:36 An: ProFox Email List profox@leafe.com Cc: profoxtech@leafe.com Betreff: Re: Office automation using VFP 10 64-bit version
Not to beat this to utter death and disfigurement...
I definitely used Automation from 32-bit VFP into 64-bit Outlook. So are we saying that if I go to 64-bit VFP (the "VFP 10") that suddenly that same code would not work?
-Charlie
[excessive quoting removed by server]
- In Outlook, I went to File, then Office Account, then clicked "About Outlook" - Near the top of the resulting screen I saw "Microsoft Outlook for Office 365 MSO (16.0.11929.20618) 64-bit" (and of course there were "TM"s spread around in that string). - Then I went to VFP and opened up the code I had used a while back. The 'basic' design of it is as follows:
oOutlook = CREATEOBJECT('outlook.application') ... oMsg = oOutlook.CreateItem(0) oMsg.to = <email address> oMsg.from = <the from address> oMsg.subject = <some subject line> oMsg.htmlbody = <my email message, a fantastically formatted and built/styled HTML message I might add.... :) >
*-- maybe there was another step or two - but you get the gist
*-- then actually sent the message. oMsg.send()
I did the above this past Friday (4/17/2020) - grabbing out some of that code and ran lines of it from the VFP command prompt (the actual code would have sent out about 100 emails for a 'crisis' situation that did not exist so I did not want to trigger that - heh). But the email I created with the above process was sent and delivered (to myself at a couple different email addresses I have). According to the "About" VFP - I am using VFP SP2, version 09.00.0000.5815.
Of course, this was ONLY Outlook. It was not Word, Excel, or Powerpoint. But it does clearly call itself 64-bit. Now.... based on MS's past behavior I certainly do not expect them to be honest. But trying to deceive at this level would seem a little ridiculous even for them.
I will add that I do not know if we perhaps started with 32-bit Office at one point and then migrated to 365 64-bit. This particular PC was set up about 11 months ago. And given MS's poor history of cleaning up after itself, there may be 32-bit libraries hanging around.
Note that I have installed 32-bit MS SQL ODBC drivers on the machine. I kind of doubt that would have an impact, but its hard to tell without a lot of library-calls tracking work (which I do not feel like doing...).
I have some Powerpoint automation code around here somewhere. Maybe I'll give that a try too.
But the thing that started this whole thread was whether or not the "VFP 10" (64bit VFP?) version would be able to do automation into "64bit" Office stuff. So even if my 32-bit example is 'magic' are we still thinking the 64bit VFP would not work with 64bit Office?
Maybe it would be worth sharing/creating several code samples that we have used for 'Office automation', store them somewhere, and then use those as a quick-test set for any new VFP release or compatible product...
-Charlie
On Sat, Apr 18, 2020 at 1:40 PM Jürgen Wondzinski juergen@wondzinski.de wrote:
Are you absolutely sure that you have Office 64bit installed? Since it's not only me, but MS itself to state that it's technically impossible, I really doubt it. :) If yes, you would be the first to made it magically happen.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von Charlie Coleman Gesendet: Samstag, 18. April 2020 18:36 An: ProFox Email List profox@leafe.com Cc: profoxtech@leafe.com Betreff: Re: Office automation using VFP 10 64-bit version
Not to beat this to utter death and disfigurement...
I definitely used Automation from 32-bit VFP into 64-bit Outlook. So are we saying that if I go to 64-bit VFP (the "VFP 10") that suddenly that same code would not work?
-Charlie
[excessive quoting removed by server]
Interesting! I have, AFAIK, the latest Office 365 running on Win 10 1909 and mine shows Microsoft Outlook for Office 365 MSO (16.0.12624.20422) 32-bit.
Curiouser and curiouser.
John
John Weller 01380 723235 07976 393631
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Charlie Coleman Sent: 20 April 2020 12:16 To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
- In Outlook, I went to File, then Office Account, then clicked "About Outlook" - Near the top of the resulting screen I saw "Microsoft Outlook for Office 365 MSO (16.0.11929.20618) 64-bit" (and of course there were "TM"s spread around in that string). - Then I went to VFP and opened up the code I had used a while back. The 'basic' design of it is as follows:
oOutlook = CREATEOBJECT('outlook.application') ... oMsg = oOutlook.CreateItem(0) oMsg.to = <email address> oMsg.from = <the from address> oMsg.subject = <some subject line> oMsg.htmlbody = <my email message, a fantastically formatted and built/styled HTML message I might add.... :) >
*-- maybe there was another step or two - but you get the gist
*-- then actually sent the message. oMsg.send()
I did the above this past Friday (4/17/2020) - grabbing out some of that code and ran lines of it from the VFP command prompt (the actual code would have sent out about 100 emails for a 'crisis' situation that did not exist so I did not want to trigger that - heh). But the email I created with the above process was sent and delivered (to myself at a couple different email addresses I have). According to the "About" VFP - I am using VFP SP2, version 09.00.0000.5815.
Of course, this was ONLY Outlook. It was not Word, Excel, or Powerpoint. But it does clearly call itself 64-bit. Now.... based on MS's past behavior I certainly do not expect them to be honest. But trying to deceive at this level would seem a little ridiculous even for them.
I will add that I do not know if we perhaps started with 32-bit Office at one point and then migrated to 365 64-bit. This particular PC was set up about 11 months ago. And given MS's poor history of cleaning up after itself, there may be 32-bit libraries hanging around.
Note that I have installed 32-bit MS SQL ODBC drivers on the machine. I kind of doubt that would have an impact, but its hard to tell without a lot of library-calls tracking work (which I do not feel like doing...).
I have some Powerpoint automation code around here somewhere. Maybe I'll give that a try too.
But the thing that started this whole thread was whether or not the "VFP 10" (64bit VFP?) version would be able to do automation into "64bit" Office stuff. So even if my 32-bit example is 'magic' are we still thinking the 64bit VFP would not work with 64bit Office?
Maybe it would be worth sharing/creating several code samples that we have used for 'Office automation', store them somewhere, and then use those as a quick-test set for any new VFP release or compatible product...
-Charlie
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled as an EXE. Fun stuff.
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Charlie Coleman Sent: Saturday, April 18, 2020 12:36 PM To: profoxtech@leafe.com Cc: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
Not to beat this to utter death and disfigurement...
I definitely used Automation from 32-bit VFP into 64-bit Outlook. So are we saying that if I go to 64-bit VFP (the "VFP 10") that suddenly that same code would not work?
-Charlie
On Sat, Apr 18, 2020 at 6:37 AM Alan Bourke alanpbourke@fastmail.fm wrote:
It's not helped by the fact that 64-bit Office will get installed by default now via Office 365, and you kind of have to jump through hoops to install the 32-bit version.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled as an EXE. Fun stuff.
What's the benefit to that?
You can write a VFP COM object that holds the business logic, and data access, if you are still using VFP Tables and update the UI with a 64-bit WPF application. Or a Web project that accesses the VFP data of a VFP desktop application. The VFP COM object could call code in the VFP Desktop application.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 10:53 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled as
an
EXE. Fun stuff.
What's the benefit to that?
So the front end C# app....it's referring to the VFP COM object properties in its UI?
On 4/21/2020 11:04 AM, Tracy Pearson wrote:
You can write a VFP COM object that holds the business logic, and data access, if you are still using VFP Tables and update the UI with a 64-bit WPF application. Or a Web project that accesses the VFP data of a VFP desktop application. The VFP COM object could call code in the VFP Desktop application.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 10:53 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled as
an
EXE. Fun stuff.
What's the benefit to that?
It could, but I just call methods in the COM object to get data.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 11:11 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
So the front end C# app....it's referring to the VFP COM object properties in its UI?
On 4/21/2020 11:04 AM, Tracy Pearson wrote:
You can write a VFP COM object that holds the business logic, and data access, if you are still using VFP Tables and update the UI with a 64-bit WPF application. Or a Web project that accesses the VFP data of a VFP desktop application. The VFP COM object could call code in the VFP Desktop application.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 10:53 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled as
an
EXE. Fun stuff.
What's the benefit to that?
What's the return type? An object with all of the properties? I'm sure you're not returning single values for everything.
On 4/21/2020 11:23 AM, Tracy Pearson wrote:
It could, but I just call methods in the COM object to get data.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 11:11 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
So the front end C# app....it's referring to the VFP COM object properties in its UI?
On 4/21/2020 11:04 AM, Tracy Pearson wrote:
You can write a VFP COM object that holds the business logic, and data access, if you are still using VFP Tables and update the UI with a 64-bit WPF application. Or a Web project that accesses the VFP data of a VFP desktop application. The VFP COM object could call code in the VFP Desktop application.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 10:53 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled as
an
EXE. Fun stuff.
What's the benefit to that?
For what I have been working on, it has been an Xml string that I can process to and from a cursor with the XmlAdapter. In C# I can process it to and from a List<T>. The XmlAdapter will nest related tables such as Orders and OrderItems and bring that back to VFP cursors from the Xml string that is returned. In C# it would be a List<Orders> and has a List<OrderItems> as one of the properties.
You have more functions available to you in the COM object then the VFP OleDB Provider.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 3:47 PM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
What's the return type? An object with all of the properties? I'm sure you're not returning single values for everything.
On 4/21/2020 11:23 AM, Tracy Pearson wrote:
It could, but I just call methods in the COM object to get data.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 11:11 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
So the front end C# app....it's referring to the VFP COM object properties in its UI?
On 4/21/2020 11:04 AM, Tracy Pearson wrote:
You can write a VFP COM object that holds the business logic, and data access, if you are still using VFP Tables and update the UI with a 64-bit WPF application. Or a Web project that accesses the VFP data of a VFP desktop application. The VFP COM object could call code in the VFP Desktop application.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 10:53 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled as
an
EXE. Fun stuff.
What's the benefit to that?
Consider making the root of the XLM object singular, such as Customer with List<Orders> as an element of it?
On Tue, Apr 21, 2020 at 3:15 PM Tracy Pearson tracy@powerchurch.com wrote:
For what I have been working on, it has been an Xml string that I can process to and from a cursor with the XmlAdapter. In C# I can process it to and from a List<T>. The XmlAdapter will nest related tables such as Orders and OrderItems and bring that back to VFP cursors from the Xml string that is returned. In C# it would be a List<Orders> and has a List<OrderItems> as one of the properties.
You have more functions available to you in the COM object then the VFP OleDB Provider.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 3:47 PM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
What's the return type? An object with all of the properties? I'm sure you're not returning single values for everything.
On 4/21/2020 11:23 AM, Tracy Pearson wrote:
It could, but I just call methods in the COM object to get data.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 11:11 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
So the front end C# app....it's referring to the VFP COM object properties in its UI?
On 4/21/2020 11:04 AM, Tracy Pearson wrote:
You can write a VFP COM object that holds the business logic, and data access, if you are still using VFP Tables and update the UI with a
64-bit
WPF application. Or a Web project that accesses the VFP data of a VFP desktop application. The VFP COM object could call code in the VFP Desktop application.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 10:53 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled
as
an
EXE. Fun stuff.
What's the benefit to that?
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Depends on what and why the data is being returned. I was just giving an example.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Stephen Russell Sent: Tuesday, April 21, 2020 5:13 PM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
Consider making the root of the XLM object singular, such as Customer with List<Orders> as an element of it?
On Tue, Apr 21, 2020 at 3:15 PM Tracy Pearson tracy@powerchurch.com wrote:
For what I have been working on, it has been an Xml string that I can process to and from a cursor with the XmlAdapter. In C# I can process it to and from a List<T>. The XmlAdapter will nest related tables such as Orders and OrderItems and bring that back to VFP cursors from the Xml string that is returned. In C# it would be a List<Orders> and has a List<OrderItems> as one of the properties.
You have more functions available to you in the COM object then the VFP OleDB Provider.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 3:47 PM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
What's the return type? An object with all of the properties? I'm sure you're not returning single values for everything.
On 4/21/2020 11:23 AM, Tracy Pearson wrote:
It could, but I just call methods in the COM object to get data.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 11:11 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
So the front end C# app....it's referring to the VFP COM object properties in its UI?
On 4/21/2020 11:04 AM, Tracy Pearson wrote:
You can write a VFP COM object that holds the business logic, and data access, if you are still using VFP Tables and update the UI with a
64-bit
WPF application. Or a Web project that accesses the VFP data of a VFP desktop application. The VFP COM object could call code in the VFP Desktop application.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Tuesday, April 21, 2020 10:53 AM To: profoxtech@leafe.com Subject: Re: Office automation using VFP 10 64-bit version
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled
as
an
EXE. Fun stuff.
What's the benefit to that?
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
You can now do this I bet.
https://www.youtube.com/watch?time_continue=522&v=j0ng2Tp01Hc&featur...
On Tue, Apr 21, 2020 at 9:54 AM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled
as an
EXE. Fun stuff.
What's the benefit to that?
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
LMAO!! #BadSteve
On 4/21/2020 11:51 AM, Stephen Russell wrote:
You can now do this I bet.
https://www.youtube.com/watch?time_continue=522&v=j0ng2Tp01Hc&featur...
On Tue, Apr 21, 2020 at 9:54 AM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 4/20/2020 9:15 AM, Tracy Pearson wrote:
You are able to use an OUT of process COM across the 64-bit & 32-bit barrier. I showed this in my 2019 SWFox session.
I was working with a 64-bit C# and accessing a VFP 9 SP 2 COM compiled
as an
EXE. Fun stuff.
What's the benefit to that?
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
LOL....yeah, that's why I started this thread about using the 64-bit version "mainly for marketing hype" so that we can say "our app is using VC++ 10 runtimes and 64-bit." -- not for any other benefit than for marketing.
On 4/17/2020 2:35 PM, Ted Roche wrote:
On Fri, Apr 17, 2020 at 2:22 PM Jürgen Wondzinski juergen@wondzinski.de wrote:
Yepp. No OLE-Automation from VFP x64 to any 32Bit product. And no admin would install the Office x64 version, since it even states in the setup, that you should use that x64 only if you have really, really, really big XLSX files etc. Bigger than 2 Gb. And it also states that Com/OLE problems.
I think you give "admins" too much credit, my friend. On many clients' new Windows 10 machines, I find Win10 64-bit, of course, and Office 64-bit. When challenged, I've been told that's the right one to install on 64-bit OSes. *eyeroll*
Of course, calling "the computer guy" they hired for the install-and-configure-gig on Craigslist an "admin" might be a stretch...
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
I actually wrote a whitepaper about that! Let me grab the relevant section (since I haven't posted the entire thing quite yet, as it's a SWFox Attendee Exclusive):
64-bit Visual FoxPro Advanced
Unbelievable as it may sound, Chen has *also* created a 64-bit version of Visual FoxPro Advanced. It compiles 64-bit apps, which of course will only run on 64-bit versions of Windows and aren’t necessarily faster than 32-bit applications. So why would we want a 64-bit version? Advantages of 64-bit VFPA More RAM
One obvious advantage of a 64-bit version is that it can take advantage of more system RAM. A quick check of MEMORY() shows that it still shows 640, same as it has since since the earliest days of Fox, so that’s not a very useful function in either version. SYS(1001), which “returns the virtual memory pool size, which is approximately four times the amount of physical memory” also shows the same value for both the 32 and 64 bit version. However, SYS(3050,1), which “returns the foreground buffer memory size” shows the same value as SYS(1001) in the 32-bit version of VFPA, but TWICE as much in the 64-bit version! VFP Advanced 64-bit can access up to 4 GB of RAM. Larger DBF Sizes?
You may be thinking that a 64-bit version of VFPA may finally allow us to overcome the 2 gigabyte limitation on DBF files. As of this writing that’s not true, but Chen says he is working on this. At that file size, you may be wise to upsize your data anyway. Better Runtime
VFP9 and VFPA (32-bit) both use the MSVCR71.dll C++ runtime behind the scenes. VFPA 64 uses the more recent and still supported MSVCR10.dll runtime. I could have sworn I saw an announcement in the last few days about Microsoft rolling all their C++ runtimes into one package, but now I can’t find it. If you find this information and share it with me before my session at Southwest Fox 2019, I’ll buy you a beer! 64-Bit ActiveX Controls and ODBC Drivers
The most compelling case for using a 64-bit version of Visual FoxPro Advanced is that it allows you to use 64-bit ActiveX controls. For example, if your client has switched over to the 64-bit version of Microsoft Office, and your application does a lot of in-process Office automation, you’re out of luck unless your application is also 64-bit. Visual FoxPro 9 and even the 32-bit version of VFPA simply cannot use 64-bit ActiveX controls and COM objects, and there are some compelling 64-bit only controls, such as the ones from longtime Southwest Fox supports DBi Technologies ( https://www.dbi-tech.com/).
[image: ctxTreeView - 64 bit ActiveX Control - Studio Controls COM 64][image: Text Box: Figure 5: DBi's TreeView Control][image: dbi gauge Win Froms control - Data Acquisition - multiple gauge objects in a single gauge control - from DBI Technologies Inc.]
Figure 6: DBi's Gauge Control
Similarly, you can take advantage of 64-bit ODBC drivers and their larger capacities.
Disadvantages of 64-bit VFPA 32-Bit Controls and Drivers Do Not Work
If you have 32-bit ActiveX controls in your VFP application, they will not work and will need to be upgraded (if an upgrade can even be found). This includes some MDAC and Jet DAO drivers. The control this might affect most is the oleTreeView control that ships with MSCOMCTL32.ocx. There is no 64-bit equivalent, so you’ll have to refactor your code to use the DBi Technologies TreeView control (Figure 5) . ListView, DateTimePicker, and other controls in that package will also be affected. Is it Compatible with 32-bit VFPA?
Chen has done extensive work to make the 64-bit version of VFPA completely compatible with the 32-bit version. Any incompatibilities stem from circumstances beyond his control, like the ActiveX issues. He has extensively tested the DECLARE commands for using Windows APIs in VFP and claims most of them work, but not all of them.
When I tried running GoFish5 in the 64-bit version of VFPA it failed because GoFish5 uses TreeView and other 32-bit ActiveX controls. It will have to be refactored for 64-bit.
[image: Text Box: IF TYPE("_win64") = "L" AND _win64 ? "VFP Advanced 64-bit code" ELSE IF TYPE("_win64") = "L" AND ! _win64 ? "VFP Advanced 32-bit code" ELSE ? "VFP 9.0 or before code" ENDIF ENDIF]Chen has added a new _WIN64 constant that is only .T. for VFPA 64. This will allow for testing and conditional compilation of your applications, so you won’t have to maintain two separate codebases.
Conclusion Regarding 64-Bit Visual FoxPro Advanced
It’s unknown how long vendors of 3rd party controls will continue to produce and support their 32-bit versions, or for that matter how long Microsoft will continue to put out 32-bit versions of Windows since most computers are 64-bit these days. Having a 64-bit option gives FoxPro developers the possibility of moving into an all 64-bit future, alleviating a grave concern. Because it’s not a seamless transition, developers who want to ensure this future should begin testing their development tools (like GoFish) and their own applications in 64-bit VFPA to see what’s possible.
On Thu, Apr 16, 2020 at 1:50 PM Charlie Coleman ccbibleman@gmail.com wrote:
Quick question. Are you all saying there is no Automation available to MS Office products in the 64-bit world?
I recently wrote a quick VFP app to 'automate' Outlook (ref: createobject('outlook.application')) to generate and send a bunch of emails. The Outlook 365 was 64-bit (I think). Are you saying I would not have been able to do that if I would have used the 'VFP 10' runtimes, etc? I understand ActiveX/FLLs that were compiled 32-bit would be an issue - if they did not have a 64-bit version included.
-Charlie
On Thu, Apr 16, 2020 at 1:30 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
Ah yes, the automation angle. Temporarily forgot about that. Thanks, wOOdy!
On 4/16/2020 1:24 PM, Jürgen Wondzinski wrote:
You are correct, there is no reason to have a 64bit FoxPro application
for a regular Desktop app. It is different for building the middle-tier
of
a distributed app or a Webserver extension. But on a regular desktop you gain nothing, but inherit a lot of problems: No support for regular 32bit ActiveX or FLL components. No COM-control of Office or other 32Bit stuff.
Thus you better use the 32Bit version of VFPA, which is really highly
recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software
Solutions, LLC
Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that
IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M
NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
So VFPA (32-bit) uses the same runtime as VFP9SP3? Oh. There goes that marketing line. (I thought it was using the VC++ 10 runtime.)
On 4/21/2020 2:41 PM, Eric Selje wrote:
I actually wrote a whitepaper about that! Let me grab the relevant section (since I haven't posted the entire thing quite yet, as it's a SWFox Attendee Exclusive):
64-bit Visual FoxPro Advanced
Unbelievable as it may sound, Chen has *also* created a 64-bit version of Visual FoxPro Advanced. It compiles 64-bit apps, which of course will only run on 64-bit versions of Windows and aren’t necessarily faster than 32-bit applications. So why would we want a 64-bit version? Advantages of 64-bit VFPA More RAM
One obvious advantage of a 64-bit version is that it can take advantage of more system RAM. A quick check of MEMORY() shows that it still shows 640, same as it has since since the earliest days of Fox, so that’s not a very useful function in either version. SYS(1001), which “returns the virtual memory pool size, which is approximately four times the amount of physical memory” also shows the same value for both the 32 and 64 bit version. However, SYS(3050,1), which “returns the foreground buffer memory size” shows the same value as SYS(1001) in the 32-bit version of VFPA, but TWICE as much in the 64-bit version! VFP Advanced 64-bit can access up to 4 GB of RAM. Larger DBF Sizes?
You may be thinking that a 64-bit version of VFPA may finally allow us to overcome the 2 gigabyte limitation on DBF files. As of this writing that’s not true, but Chen says he is working on this. At that file size, you may be wise to upsize your data anyway. Better Runtime
VFP9 and VFPA (32-bit) both use the MSVCR71.dll C++ runtime behind the scenes. VFPA 64 uses the more recent and still supported MSVCR10.dll runtime. I could have sworn I saw an announcement in the last few days about Microsoft rolling all their C++ runtimes into one package, but now I can’t find it. If you find this information and share it with me before my session at Southwest Fox 2019, I’ll buy you a beer! 64-Bit ActiveX Controls and ODBC Drivers
The most compelling case for using a 64-bit version of Visual FoxPro Advanced is that it allows you to use 64-bit ActiveX controls. For example, if your client has switched over to the 64-bit version of Microsoft Office, and your application does a lot of in-process Office automation, you’re out of luck unless your application is also 64-bit. Visual FoxPro 9 and even the 32-bit version of VFPA simply cannot use 64-bit ActiveX controls and COM objects, and there are some compelling 64-bit only controls, such as the ones from longtime Southwest Fox supports DBi Technologies ( https://www.dbi-tech.com/).
[image: ctxTreeView - 64 bit ActiveX Control - Studio Controls COM 64][image: Text Box: Figure 5: DBi's TreeView Control][image: dbi gauge Win Froms control - Data Acquisition - multiple gauge objects in a single gauge control - from DBI Technologies Inc.]
Figure 6: DBi's Gauge Control
Similarly, you can take advantage of 64-bit ODBC drivers and their larger capacities.
Disadvantages of 64-bit VFPA 32-Bit Controls and Drivers Do Not Work
If you have 32-bit ActiveX controls in your VFP application, they will not work and will need to be upgraded (if an upgrade can even be found). This includes some MDAC and Jet DAO drivers. The control this might affect most is the oleTreeView control that ships with MSCOMCTL32.ocx. There is no 64-bit equivalent, so you’ll have to refactor your code to use the DBi Technologies TreeView control (Figure 5) . ListView, DateTimePicker, and other controls in that package will also be affected. Is it Compatible with 32-bit VFPA?
Chen has done extensive work to make the 64-bit version of VFPA completely compatible with the 32-bit version. Any incompatibilities stem from circumstances beyond his control, like the ActiveX issues. He has extensively tested the DECLARE commands for using Windows APIs in VFP and claims most of them work, but not all of them.
When I tried running GoFish5 in the 64-bit version of VFPA it failed because GoFish5 uses TreeView and other 32-bit ActiveX controls. It will have to be refactored for 64-bit.
[image: Text Box: IF TYPE("_win64") = "L" AND _win64 ? "VFP Advanced 64-bit code" ELSE IF TYPE("_win64") = "L" AND ! _win64 ? "VFP Advanced 32-bit code" ELSE ? "VFP 9.0 or before code" ENDIF ENDIF]Chen has added a new _WIN64 constant that is only .T. for VFPA 64. This will allow for testing and conditional compilation of your applications, so you won’t have to maintain two separate codebases.
Conclusion Regarding 64-Bit Visual FoxPro Advanced
It’s unknown how long vendors of 3rd party controls will continue to produce and support their 32-bit versions, or for that matter how long Microsoft will continue to put out 32-bit versions of Windows since most computers are 64-bit these days. Having a 64-bit option gives FoxPro developers the possibility of moving into an all 64-bit future, alleviating a grave concern. Because it’s not a seamless transition, developers who want to ensure this future should begin testing their development tools (like GoFish) and their own applications in 64-bit VFPA to see what’s possible.
On Thu, Apr 16, 2020 at 1:50 PM Charlie Coleman ccbibleman@gmail.com wrote:
Quick question. Are you all saying there is no Automation available to MS Office products in the 64-bit world?
I recently wrote a quick VFP app to 'automate' Outlook (ref: createobject('outlook.application')) to generate and send a bunch of emails. The Outlook 365 was 64-bit (I think). Are you saying I would not have been able to do that if I would have used the 'VFP 10' runtimes, etc? I understand ActiveX/FLLs that were compiled 32-bit would be an issue - if they did not have a 64-bit version included.
-Charlie
On Thu, Apr 16, 2020 at 1:30 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
Ah yes, the automation angle. Temporarily forgot about that. Thanks, wOOdy!
On 4/16/2020 1:24 PM, Jürgen Wondzinski wrote:
You are correct, there is no reason to have a 64bit FoxPro application
for a regular Desktop app. It is different for building the middle-tier
of
a distributed app or a Webserver extension. But on a regular desktop you gain nothing, but inherit a lot of problems: No support for regular 32bit ActiveX or FLL components. No COM-control of Office or other 32Bit stuff.
Thus you better use the 32Bit version of VFPA, which is really highly
recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software
Solutions, LLC
Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that
IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF I'M
NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for marketing my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
It did as of that writing. Since the 32 bit version isn't a recompile like the 64 bit version is, it would make sense that it's the same.
Speaking of marketing lines, my proposal for this year's SWFox sessions is something along the lines of "Preparing your defense of using Visual FoxPro in 2020". We'll see...
On Tue, Apr 21, 2020 at 2:55 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
So VFPA (32-bit) uses the same runtime as VFP9SP3? Oh. There goes that marketing line. (I thought it was using the VC++ 10 runtime.)
On 4/21/2020 2:41 PM, Eric Selje wrote:
I actually wrote a whitepaper about that! Let me grab the relevant
section
(since I haven't posted the entire thing quite yet, as it's a SWFox Attendee Exclusive):
64-bit Visual FoxPro Advanced
Unbelievable as it may sound, Chen has *also* created a 64-bit version of Visual FoxPro Advanced. It compiles 64-bit apps, which of course will
only
run on 64-bit versions of Windows and aren’t necessarily faster than
32-bit
applications. So why would we want a 64-bit version? Advantages of 64-bit VFPA More RAM
One obvious advantage of a 64-bit version is that it can take advantage
of
more system RAM. A quick check of MEMORY() shows that it still shows 640, same as it has since since the earliest days of Fox, so that’s not a very useful function in either version. SYS(1001), which “returns the virtual memory pool size, which is approximately four times the amount of
physical
memory” also shows the same value for both the 32 and 64 bit version. However, SYS(3050,1), which “returns the foreground buffer memory size” shows the same value as SYS(1001) in the 32-bit version of VFPA, but
TWICE
as much in the 64-bit version! VFP Advanced 64-bit can access up to 4 GB of RAM. Larger DBF Sizes?
You may be thinking that a 64-bit version of VFPA may finally allow us to overcome the 2 gigabyte limitation on DBF files. As of this writing
that’s
not true, but Chen says he is working on this. At that file size, you may be wise to upsize your data anyway. Better Runtime
VFP9 and VFPA (32-bit) both use the MSVCR71.dll C++ runtime behind the scenes. VFPA 64 uses the more recent and still supported MSVCR10.dll runtime. I could have sworn I saw an announcement in the last few days about Microsoft rolling all their C++ runtimes into one package, but now
I
can’t find it. If you find this information and share it with me before
my
session at Southwest Fox 2019, I’ll buy you a beer! 64-Bit ActiveX Controls and ODBC Drivers
The most compelling case for using a 64-bit version of Visual FoxPro Advanced is that it allows you to use 64-bit ActiveX controls. For
example,
if your client has switched over to the 64-bit version of Microsoft
Office,
and your application does a lot of in-process Office automation, you’re
out
of luck unless your application is also 64-bit. Visual FoxPro 9 and even the 32-bit version of VFPA simply cannot use 64-bit ActiveX controls and COM objects, and there are some compelling 64-bit only controls, such as the ones from longtime Southwest Fox supports DBi Technologies ( https://www.dbi-tech.com/).
[image: ctxTreeView - 64 bit ActiveX Control - Studio Controls COM
64][image:
Text Box: Figure 5: DBi's TreeView Control][image: dbi gauge Win Froms control - Data Acquisition - multiple gauge objects in a single gauge control - from DBI Technologies Inc.]
Figure 6: DBi's Gauge Control
Similarly, you can take advantage of 64-bit ODBC drivers and their larger capacities.
Disadvantages of 64-bit VFPA 32-Bit Controls and Drivers Do Not Work
If you have 32-bit ActiveX controls in your VFP application, they will
not
work and will need to be upgraded (if an upgrade can even be found). This includes some MDAC and Jet DAO drivers. The control this might affect
most
is the oleTreeView control that ships with MSCOMCTL32.ocx. There is no 64-bit equivalent, so you’ll have to refactor your code to use the DBi Technologies TreeView control (Figure 5) . ListView, DateTimePicker, and other controls in that package will also be affected. Is it Compatible with 32-bit VFPA?
Chen has done extensive work to make the 64-bit version of VFPA
completely
compatible with the 32-bit version. Any incompatibilities stem from circumstances beyond his control, like the ActiveX issues. He has extensively tested the DECLARE commands for using Windows APIs in VFP and claims most of them work, but not all of them.
When I tried running GoFish5 in the 64-bit version of VFPA it failed because GoFish5 uses TreeView and other 32-bit ActiveX controls. It will have to be refactored for 64-bit.
[image: Text Box: IF TYPE("_win64") = "L" AND _win64 ? "VFP Advanced
64-bit
code" ELSE IF TYPE("_win64") = "L" AND ! _win64 ? "VFP Advanced 32-bit code" ELSE ? "VFP 9.0 or before code" ENDIF ENDIF]Chen has added a new _WIN64 constant that is only .T. for VFPA 64. This will allow for testing and conditional compilation of your applications, so you won’t have to maintain two separate codebases.
Conclusion Regarding 64-Bit Visual FoxPro Advanced
It’s unknown how long vendors of 3rd party controls will continue to produce and support their 32-bit versions, or for that matter how long Microsoft will continue to put out 32-bit versions of Windows since most computers are 64-bit these days. Having a 64-bit option gives FoxPro developers the possibility of moving into an all 64-bit future,
alleviating
a grave concern. Because it’s not a seamless transition, developers who want to ensure this future should begin testing their development tools (like GoFish) and their own applications in 64-bit VFPA to see what’s possible.
On Thu, Apr 16, 2020 at 1:50 PM Charlie Coleman ccbibleman@gmail.com wrote:
Quick question. Are you all saying there is no Automation available to
MS
Office products in the 64-bit world?
I recently wrote a quick VFP app to 'automate' Outlook (ref: createobject('outlook.application')) to generate and send a bunch of emails. The Outlook 365 was 64-bit (I think). Are you saying I would not have been able to do that if I would have used the 'VFP 10' runtimes,
etc?
I understand ActiveX/FLLs that were compiled 32-bit would be an issue -
if
they did not have a 64-bit version included.
-Charlie
On Thu, Apr 16, 2020 at 1:30 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
Ah yes, the automation angle. Temporarily forgot about that. Thanks, wOOdy!
On 4/16/2020 1:24 PM, Jürgen Wondzinski wrote:
You are correct, there is no reason to have a 64bit FoxPro application
for a regular Desktop app. It is different for building the middle-tier
of
a distributed app or a Webserver extension. But on a regular desktop
you
gain nothing, but inherit a lot of problems: No support for regular
32bit
ActiveX or FLL components. No COM-control of Office or other 32Bit
stuff.
Thus you better use the 32Bit version of VFPA, which is really highly
recommended, since it cures a lot of old bugs.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software
Solutions, LLC
Gesendet: Donnerstag, 16. April 2020 17:28 An: ProFox Email List profox@leafe.com Betreff: 64-bit app via the Chen version
I finally I downloaded the VFPA runtime files and am going to use that
IDE and develop/deploy with this "VFP 10" version since many here have spoken of it without much negativity.
Question: what would be the benefit of using the 64-bit version IF
I'M
NOT USING DBFS (because in my MBSS apps, I use MariaDB/MySQL as the backend, not VFP). I just don't see the benefit other than for
marketing
my apps to say "they're 64-bit using the VC++ 10 runtimes."
tia, --Mike
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
-
Alan Bourke -
Charlie Coleman -
Eric Selje -
John Weller -
Jürgen Wondzinski -
MB Software Solutions, LLC -
Richard Kaye -
Stephen Russell -
Ted Roche -
Tracy Pearson