I am trying to embed a picture file in my html string and send out the email using VB6.
I need to use this function AddRelatedBodyPart in the library of Microsoft CDO for Exchange 2000 Library.
Can someone please help me to install this library in VB6. Thanks
You need MAPI for Exchange 2000: MSMAPI32.OCX and cdosys.dll.
If you don't find such an old installer, may be googling on the net you will be able to find the correct version of this two files. Then, copy and register this two files by hand:
For example: regsvr32 %windir%\system32\cdosys.dll
A note aside: On a 64-bit version of Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
Be sure to use the 32bit version.
To test the successfully installation, in the VBIDE go to Project->References and add "Microsoft CDO for Windows 2000 Library".
Now, press F2 to open the Object Browser. You should be able to find the function you need.
Related
I maintain a large VB6 application I would like to be able to install on Windows 10. It has a large Help file in WinHelp format. I would like to distribute winhlp32.exe (and winhlp32.exe.mui) with the application rather than replace the winhlp32.exe file in the Windows 10 Windows folder. If I put (an old) winhlp32.exe file in the application folder in Windows 10, and file winhlp32.exe.mui in a subfolder named en-US, the help file works if I enter the command "winhlp32.exe myhelpfile.hlp" in the application folder. However if I run the application exe (created by VB6), and press F1, it runs the Windows 10 winhlp32.exe stub, not the winhlp32.exe in the application folder.
Can anyone suggest how to persuade the VB6 application (before or after compiling it) to use winhlp32.exe from the application folder instead of the Windows folder?
The short story - you may be warned and you know in all it's a heavy task to migrate your VB6 app maybe without reaching a simple way for migrating WinHelp to HTMLHelp.
The official recommendation (10 years old):
Forget about WinHelp, it's history and migrate to CHM help file format.
But, maybe you already have found my answer (search for Run WinHelp on Windows10) and read all further links:
How to convert HLP files into CHM files
Please note a tool called HHPMod especially for migrating context-sensitive F1 help.
I tried the WinHelp of an old VB6 program before and after the fix from above and it is working for me on Windows 10 (Version 1803).
Another solution you may want to try (depends on your deploy and IT environment):
Windows Help Program (WinHlp32.exe) for Windows 8.1 and Windows 7 x64 and x86
Quoted from this article (thanks to Komeil Bahmanpour):
"Please note users who have tried to replace winhlp32.exe manually in Windows folder and winhlp32.exe.mui in Windows\en-US folder of Windows 7, was faced with overwrite restrictions due to ownership and permission problems."
Additional information:
I may well be wrong, but I believe that also (old) online help files are usually copyrighted as part of Microsoft Windows. Distributing the files would normally constitute a violation of copyright law (as you mentioned in your question).
AFAIK developers are not allowed to distribute the Vista version of WinHlp32.exe or included it in their installations. Every individual user who wants to use WinHelp must download the WinHelp update directly from Microsoft and install it themselves.
Help for applications has been .chm for many many years now. Microsoft released the tool HH Workshop (HTMLHelp SDK 1.4) around 1997. Around March 2006 during discussions with MVPs, Microsoft Help team announced that WinHelp would be deprecated (phased out). WinHelp is architected in such a way that Microsoft would have to rewrite it from the ground up to meet the Windows Vista code standards. Since then .CHM has been the only choice for our application help.
What does this mean (please note we are about ten years later now!):
WinHelp runtime (WinHelp32.exe) no longer ships with Windows Vista/7/8/10
ISVs (Independant Software Vendors) should stop promoting WinHelp as a viable help system.
Help authors should move over to HTML Help 1.x (.chm) if they haven't done so already.
HH Workshop is sufficient to author .CHM help files. I'm using a tool with a few more features (drag and drop TOC/Index editing etc) called "FAR HTML". Then there are high-end more expensive tools (you mentioned RoboHelp) that have advanced features such as "convert between different help systems".
Try (untested, but you should get the idea)
Shell App.Path & "\winhlp32.exe myhelpfile"
App.Path gets the executable's current path, so just make sure your winhlp32.exe file is right there with it.
I want to convert an MSG file (Outlook mail message saved as a file) to an EML (RFC822) file. I'd also like to reverse the procedure and convert the resultant EML file back to MSG. From what I read, I can do this with Redemption via VBScript.
I don't have or desire to have Outlook installed, so I installed Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 on my Windows 64-bit machine as recommended on the Redemption page. I'm trying to run the following code:
Set session = CreateObject("Redemption.RDOSession")
Set msg = session.GetMessageFromMsgFile("c:\temp\mail.msg", false)
msg.SaveAs "c:\temp\mail.eml", 1024
I get an error that states "Wrong OS or OS version". The OS is 64-bit, and Redemption installed as 64-bit, so I'm guessing the standalone MAPI library installed as 32-bit.
Does anyone know if I can get this to work with Redemption? If not, does anyone have other suggestions to convert these file types without having Outlook installed?
Your app bitness must match the bitness of the MAPI system, there is no way around that. See http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject for details.
You can either install the 64 bit version of Outlook (any version) or compile your app in 32 bit (x86).
Keep in mind that the standalone version of MAPI does not handle Unicode MSG files.
How would I get a list of EVERY program into a text file for windows 95-windows 10. The uninstall programs in control panel doesn't have the version and publisher for the older operating systems, and wmic does not display every program. Even the uninstall registry, which I thought would be my savior, does not list every program. I can see discrepancies between that and the uninstall programs tab. Powershell and the like are off the table since it is relatively new.
Some combination of the following:
Enumerate registry for HKEY_CURRENT_USER\Software\Microsoft\CurrentVersion\Uninstall and HKEY_LOCAL_MACHINE\Software\Microsoft\CurrentVersion\Uninstall. And probably HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall on 64-bit os (might be duplicated). These are the list of installed programs that appear in the Control Panel's "Program and Features" section. Notice that some of the entries are straight-forward and have most of the data you want. Others are a GUID - this corresponds to an MSI installation.
For all the entries obtained in #1 that reference a GUID, use the MSI API to find the installation information you seek. Start with MsiEnumProducts. From there you can get at version info of installed applications.
Brute force search for EXEs installed in C:\Program Files and C:\Program Files (x86). For each EXE found, you can use this method to get the version information.
You want a list of applications installed from the Windows Store? Ask me for a code sample if that's important too.
The registry uninstall registration requirements in the 90's was just the display name and the command to start the uninstallation. Windows 2000 added support for more values and exposed them in the new UI but they were still optional. In recent years a couple of them became a requirement to pass the Windows Logo tests but they are still optional for non-certified applications so the uninstall key is not guaranteed to contain version/publisher information for every entry. Portable applications are not listed in the registry so if you need a inventory of everything then you need to inspect all exe files and ignore the registry.
Supporting everything back to Win95 RTM is going to be tough since you have nothing except batch files as a scripting option. VBScript is a optional component that normally gets installed with IE 4 and I don't even remember if it is possible to get Powershell on these systems.
I don't think it is possible to extract the version information with a simple batch file, you probably need the help of a 3rd-party tool. The issue with 3rd-party tools is that a lot of them depend on the Microsoft CRT run-time .DLLs and Windows 95 RTM does not have them out of the box, not even msvcrt.dll.
If you can raise your requirement for Win95 to have Windows Scripting Host installed (redistributable or part of IE4) then you could write a VB/Jscript file that uses the FileSystemObject to both walk the entire directory tree on every drive and to get version information from .exe files.
If that is unacceptable then you need to try to find a tool that can extract version information. There is a Microsoft tool named filever.exe listed here but I don't know if it works on Win95 and a NirSoft tool here but I'm not sure if it supports stdout redirection from the commandline (but it is open source so you could fix that if needed). Even if you find a suitable tool you would still need to walk the directory tree looking for .exe files and that is not going to be fun when you are limited to command.com and its DOS compatible batch handling.
My recommendation is to write a new application. I can't recommend writing it in a .NET language because you would be dealing with versions 1-4 and it is not installed on XP and older by default.
The way I see it, you have 3 options if you are writing it yourself: Visual Basic 6, Delphi (something old, v3 or older perhaps) or C/C++.
For C/C++ any version of Microsoft Visual C++ or MinGW/GCC will do but the older the better and you must not link to or use any C run-time library stuff (you might get away with static linking with MinGW but not recent versions of Visual Studio). If I was doing this I would use Visual Studio 6 or 2003 and build with /Zl & /NODEFAULTLIB. There are multiple small standalone CRT libraries if you need them. If you use any recent version of Visual Studio you will manually have to hex-edit the file to make it run on anything older than XP.
The actual implementation needs to call FindFirstFileA (and friends) on Windows 95/98/ME and FindFirstFileW on other systems to walk the directory tree and GetFileVersionInfoA/W (and friends) to get version info.
If you are feeling fancy you could perhaps filter out files in %WinDir% signed by Microsoft. Good luck...
I am unable to index contents of LibreOffice files. Files such as .odt files cannot be indexed on Windows Search.
The error says "Registered IFilter is not found"
Any help please?
You installed all the needed optional components i libreoffice installer ?
In the optional features you can select some features that doesn't came in the typical installation.
here is a quick link to a video tutorial an step by step description on how to install LibreOffice
LibreOffice supplies IFilters for 64-bit. Today I updated to 3.6.3.2 on W7_64. The update installed its filters and they did not work. I revert back to the filter from IFilterShop. This one does work (need to read the readme for Vista and W7). Its free for non-commercial usage.
IFilters are used to convert file formats into text for searching. The trouble is that they need to be the same 'bitness' as the app that wants to load them. So if you have a 64-bit app that wants to use the IFilters you need 64-bit IFilters installed.
Have you installed 64-bit Libre Office?
I created a Delphi application which utilizes an ODBC data source to access text files in csv format. The driver is the "Microsoft Access Text Driver". But when I deploy my application on a Windows 7 computer it does not work because this driver is not available (there are only two available in odbcad32: sql native client and sql server)
How can I install this driver? I have tried to install MDAC, but it doesn't do anything. No errors or anythinig, but it just shows a quick scroll bar and that is it. And I have heard that MDAC has been replaced by WDAC on Windows 7.
EDIT: I should add this is Windows 7 Home, not Professional.
You have to run the ODBC Administrator from this location:
C:\Windows\SysWOW64\odbcad32.exe
then you will see all the x32 drivers
You might have to install the Microsoft Jet driver. I believe that Microsoft broke it out of MDAC awhile back, and it is no longer be installed by default.
EDIT After further research it appears that they have removed the text file drivers from the jet engine entirely. You can still use the Microsoft ODBC DB Provider for ODBC Drivers to access dBase and Excel files, but no longer text files.
Project JEDI has an open source TJvCSVDataSet
Why not lighten it up and use a VCL TStringList with TStringList.LoadFromFile() and forget about ODBC, MDAC, WDAC and whatever else weighs down the task at hand?
I found I could access the Microsoft text Driver if my application is compiled targeting x86 cpus.
I believe you'll need to install this package to get the text driver (among others).
Here's a CSV demo that doesn't require you to install any components or write any parsing code. If you can call my class .Create method, you can use this code without installing anything.
It uses two unit files that implement the JvCsvDataSet component, which is still a class, which can be instantiated the same way you can create a TStringList, you just create a TJvCsvDatSet.