Send E-Mail 1

[1962dez]

I was normally sending E-Mail from my VFP9 application.
I compiled the project with VFP 10.2 64 Bits and when I send E-Mail, I am getting the following error:
(SetClrVersion entry point cannot be found in the DLL)
Can anyone help me resolve the error?
Thank you in advance.

 

[Mike Lewis]

You'll have to give us more information. In particular, what tool or component are you using for this job?

Mike

 

[Joe Crescenzi]

I was normally sending E-Mail from my VFP9 application.
I compiled the project with VFP 10.2 64 Bits and when I send E-Mail, I am getting the following error:
(SetClrVersion entry point cannot be found in the DLL)
Can anyone help me resolve the error?
Thank you in advance.

Although I don't use West Wind, your error suggest that you do, and Rick Strahl's support forum points to two potential causes, either the library is not in the path, or that it's not using the .Net components as the documentation says it should.

The wildcard here is whether it's not compatible with the 64 bit VFPA. You may need to confirm that with them.

can't find entry point SetClrVersion in the dll ,can't find entry point ClrCreateInstanceForm in the dll ,Variable 'LNDISPANDHLE' is not found , unab - West Wind Technologies Support

support.west-wind.com

 

[SitesMasstec]

Try to direct the e-mails generated by your VFP application to the Outgoing box to the Thunderbird e-mall program.
You have to install the Thunderbird program and set it to your default e-mail application. You can have an e-mail address just for sending messages automatically.

 

[GTGeek88]

I was normally sending E-Mail from my VFP9 application.
I compiled the project with VFP 10.2 64 Bits and when I send E-Mail, I am getting the following error:
(SetClrVersion entry point cannot be found in the DLL)
Can anyone help me resolve the error?
Thank you in advance.

It's likely best to get your existing setup working and you have some suggestions on that, already. If you need to change for some reason, I've used BLAT in the past with good success, but now I'm mainly using SwithMail.

 

[Steve Yu]

Although I don't use West Wind, your error suggest that you do, and Rick Strahl's support forum points to two potential causes, either the library is not in the path, or that it's not using the .Net components as the documentation says it should.

The wildcard here is whether it's not compatible with the 64 bit VFPA. You may need to confirm that with them.

can't find entry point SetClrVersion in the dll ,can't find entry point ClrCreateInstanceForm in the dll ,Variable 'LNDISPANDHLE' is not found , unab - West Wind Technologies Support

support.west-wind.com

Very knowledgeable. we use West Wind for SMTP too, albeit in plain VFP 9 32-bit and have no issues.

 

[Chris Miller]

I think others already figured out SetClrVersion is a function of some West Windo component, maybe the DotNetBridge? Because from the top of my hat, using that bridge one of the first things to do is decide for the .NET CLR version to use, i.e. which .NET Framewwork version.

Anyway, when you do this in VFPa 64bit you also have to have a 64bit DLL, as simple as that.

I think I remember some posts of Rick Strahl saying he's not tested West Wind components with VFPa, so expecially not 64bit, but I'm not even sure the components West Wind offers for VFP are available in 64bit versions so they could be used (at your own risk) with VFPa 64bit at all. I know there's also a 32bit VFPA version. But of course, when you went for VFPA specifically to enter the 64bit world, you wouldn't benefit from reverting to 32bit, though quite a handful of fixes are applied that make VFPA 32bit advanced without going to 64bit, too.

Well, and all that said, sending mails is possible without needing to go to dotnet. So if you actually don't use .NET you still have very many options for sending mails with and without 3rd party components. So if switching to 64bit is more important to you than keeping bakwards compatibility, why not switch to anything else for sending mails? Blat is one third party component that's also available in 64bit.

 

[Steve Yu]

I think others already figured out SetClrVersion is a function of some West Windo component, maybe the DotNetBridge? Because from the top of my hat, using that bridge one of the first things to do is decide for the .NET CLR version to use, i.e. which .NET Framewwork version.

Anyway, when you do this in VFPa 64bit you also have to have a 64bit DLL, as simple as that.

I think I remember some posts of Rick Strahl saying he's not tested West Wind components with VFPa, so expecially not 64bit, but I'm not even sure the components West Wind offers for VFP are available in 64bit versions so they could be used (at your own risk) with VFPa 64bit at all. I know there's also a 32bit VFPA version. But of course, when you went for VFPA specifically to enter the 64bit world, you wouldn't benefit from reverting to 32bit, though quite a handful of fixes are applied that make VFPA 32bit advanced without going to 64bit, too.

Well, and all that said, sending mails is possible without needing to go to dotnet. So if you actually don't use .NET you still have very many options for sending mails with and without 3rd party components. So if switching to 64bit is more important to you than keeping bakwards compatibility, why not switch to anything else for sending mails? Blat is one third party component that's also available in 64bit.

My view is VFP 9.0 and VFP in general is an antiquate technology regardless how people wants and tries to improve upon it.
If it fits your purpose then just use it as is and at its most stable state in a 32-bit architecture.
When 32-bit version of VFP stops working that'd be the time to hang it up.
Sounds pessimistic but that's the future of VFP ever since Bill Gates dropped the product support.

 

[Joe Crescenzi]

My view is VFP 9.0 and VFP in general is an antiquate technology regardless how people wants and tries to improve upon it.
If it fits your purpose then just use it as is and at its most stable state in a 32-bit architecture.
When 32-bit version of VFP stops working that'd be the time to hang it up.
Sounds pessimistic but that's the future of VFP ever since Bill Gates dropped the product support.

My perspective on VFP is a bit more optimistic.

I feel the language itself still has potential beyond VFP9, but clearly not from Microsoft. Even if nobody successfully creates a new platform that can run my old code, I'm fine with that because I've come to appreciate the fact that it's stable. It hasn't changed since around 2009. Whatever worked then still works today. Most of the bugs are well documented and we know how to work around them.

I never have to worry that newer versions break my existing code. I can't say that about my .Net applications, where each time I load Visual Studio I worry about needing to update some of the endless list of libraries and configuration files that often lead to refactoring code just to make it work.

I love that the base controls work the same on every computer. Put a date into a box, and it will always validate the date. Put numbers in boxes and they have easy formatting and range support with minimal effort. Everything binds directly to my tables. In my ASP.NET apps, controls are not consistent from computer to computer, or with different browsers, date and numeric formatting and validation is a chore and not guaranteed to work in every browser the same.

I can go on, but you get the point. When you build a desktop app in VFP, youI know how it will run, and that it won't break because of an update or incompatible browser support.

Even if Microsoft eventually drops support for 32-bit applications in their mainstream desktop operating systems like Apple did a long time ago, I will continue to host them using remote desktops running virtual environments that still support 32-bit applications, and I don't see them dropping that any time soon.

 

[Steve Yu]

My perspective on VFP is a bit more optimistic.

I feel the language itself still has potential beyond VFP9, but clearly not from Microsoft. Even if nobody successfully creates a new platform that can run my old code, I'm fine with that because I've come to appreciate the fact that it's stable. It hasn't changed since around 2009. Whatever worked then still works today. Most of the bugs are well documented and we know how to work around them.

I never have to worry that newer versions break my existing code. I can't say that about my .Net applications, where each time I load Visual Studio I worry about needing to update some of the endless list of libraries and configuration files that often lead to refactoring code just to make it work.

I love that the base controls work the same on every computer. Put a date into a box, and it will always validate the date. Put numbers in boxes and they have easy formatting and range support with minimal effort. Everything binds directly to my tables. In my ASP.NET apps, controls are not consistent from computer to computer, or with different browsers, date and numeric formatting and validation is a chore and not guaranteed to work in every browser the same.

I can go on, but you get the point. When you build a desktop app in VFP, youI know how it will run, and that it won't break because of an update or incompatible browser support.

Even if Microsoft eventually drops support for 32-bit applications in their mainstream desktop operating systems like Apple did a long time ago, I will continue to host them using remote desktops running virtual environments that still support 32-bit applications, and I don't see them dropping that any time soon.

Points well taken. Push comes to shove, hosting legacy VFP apps under a virtual machine with compatible OS should always work as a last resort. Until 2049 that is; then someone has to figure out how to mitigate the Y2K issue again. We are still running character mode apps, 80x25 display with keyboard input. And all date fields are either c(8) or Date type with picture clauses of 'mm/dd/yy'. Antiquated interface aside, the apps are as powerful as any 'modern' systems. As you mentioned VFP 9.0 is very stable, tried and true FTP, text file, plus XML,Json capabilities to certain degree, enable us to run online real-time integration with our trading partners as well as market giants like Amazon, Walmart with ease. We also employ West Wind's web tools to drive our website for supply chain links to our overseas vendors and domestic customers. Recently we completed a monumental conversion from good-old .dbf .ndx file system to a MS SQL backend - while keeping the exact same UI tp which users have grown familiar for the last 30 years. No complaint.

 

[Chris Miller]

Just be pragmatic about this, if you want to go 64bit, then also take care of the fact all your 32bit DLLs have to be replaced by something else.

If my guess on using the West Wind dotnet bridge is correct, then there's also a question here, that shows this error can come up, if you just don't use the bridge component correctly, not depending on whether it's used from VFPA or VFP9 32 or 64 bit: https://support.west-wind.com/Thread50G0TBB5K.wwt

But if the reason isn't misplacing DLLs or not providing all components as required by the wwDotNetBridge documentation, then what can help - on the basis there is a 64bit version of the wwDotNetBridge.dll - to reuse a mail component you use in .NET is making it a COM component in the form of an EXE COM Server- and use that from VFPA via the bridge as an OLE object, because an EXE COM server is used by instanciation of a COM class and starts its own process. Just like you can automatte 64bit Office applications from VFP9 32bit, you can use a 32bit EXE COM server from VFPA 64bit.

Well, and if there isn't a 64bit wwDotNetBridge.dll then you can still use that idea of a 32bit EXE COM Server, if you just make a COM visible .NET executable from your .NET source code. If you go that way, you can also instead compile a 64bit EXE usable without the wwDotNetBridge, though. That's even more straight forward.