I have a VB6 system (about to be rewritten in VB.NET) that builds contract documents using text passages held in rtf format.
Via the system I make decisions from information incorporated in these text passages and piece together the correct passages that are necessary for the specific case.
Part of the system is to position the "called in" text passages correctly based on the tabs and indents in the calling text passages. This means that my system identifies the tab and indent points and resets them as is required.
This system has been successfully in operation since early 1980's and it is only now that two clients have requested to upgrades to MS Word 2010 and MS Word 2016 that my build is going haywire.
I assume this is to do with a change to the RTF codes and, if so, I need to either (a) rebuild my document processing module which is a major task, or (b) have a method of keeping the conversion to RTF in MS Word to the levels of MS Word 2003 or earlier even though the MS Word 2010 and/or MS Word 2016 will be loaded and operative on the users desktops.
Any suggestions would be greatly appreciated
Thanks
Mac
Related
I've come across a handful of questions relating to older version of SSRS/SQL Server but nothing recent relating to this issue with SQL Server 2012. I cannot understand why this apparent bug would not be fixed when reported since SQL Server 2008.
Anyone, my question, has anyone had a similar issue and found a solution to a report in SSRS looking fine when previewed in Visual Studio as well as the default view on the server? Yet when I print preview, print or export to PDF, my selected font of Garamond is being replaced by a generic MS Sans Serif. Exporting to Word and Excel do not seem to suffer this bug. If you look at the properties in the resulting PDF, the Garamond is not there, just two generic MS fonts. When printing, the text flows as if the Garamond is there but words are being chopped off in every element on the page.
Apparently other users have had this bug and submitted an issue to Microsoft.
https://connect.microsoft.com/SQLServer/feedback/details/546276/ssrs-report-printing-the-wrong-font
It's over 5 years old and while it is still open, Microsoft hasn't said that they will fix it which means they probably never will - even though there are no workarounds.
Here's another one from 7 years ago that was closed for no reason:
https://connect.microsoft.com/SQLServer/feedback/details/403130/sql-reporting-services-2008-print-rendering-issue-font-replacement-font-missing-character-space-compression
They have some threshold of how many people experience the error AND follow the proper Microsoft procedure (like have lengthy instructions so they can repro) for reporting it (so about 1 in 10,000) before they think about addressing an issue. If enough people ask, they'll probably change this Bug from Active to Works As Designed.
I make intensive use of Office autocorrect feature for fast typing (which I use as a kind of autocompletion - shorthand / stenography). I have been able to modify the ACL file for Office 2011 applications (which works great in Word), but Office 365 comes with a separate 2015 version of Outlook and I cannot find the dedicated file for autocorrect entries. After a few tests, I found out that Outlook does take the Mac OS system dictionary entries into account (which are stored in an .sqlite file in /Library/Dictionaries/CoreDataUbiquitySupport/username/UserDictionary/local/store/UserDictionary.db - in case you're wondering where it was...). So I have been able to add my own dictionary entries in this sqlite file and Outlook does take them into account. Heck, Outlook gets real slow when this system dictionary is fed with more than 3000 entries (I bet you're wondering wtf is in this list, never mind). Luckily, I found out that Outlook's Autocorrect feature also uses its own set of entries (which can be manually updated through Outlook Preferences > Autocorrect) - these work better and faster. So now I just need to find this damn' little file where I can store my huge list of words through a bulk import...
A long search on the Web made me realize I am probably a very lonely user of Outlook's autocorrect feature (at least on Mac)... Any weird guy like me out there who would incidentally know the path to this golden little file?
Thanks in advance,
The real place to find this is in the Group Containers folder:
/Users/user_name/Library/Group Containers/UBF8T346G9.Office/Microsoft Office ACL [English].acl
Apparently you can find it here:
/Library/Dictionaries/CoreDataUbiquitySupport/{{username}}/UserDictionary/local/store/UserDictionary.db
According to this source: http://australianforexbrokersxx0.blogspot.com/2015/03/where-is-autocorrect-dictionary-file.html
I need to use the reference to Microsoft Word 97 in my VB6 development project. (Its a long story - in a nutshell if I use ref to MSWord97 then I can support Word 97+).
I use Microsoft Word 2007 on my development machine. Ideally if I could get away with NOT installing Word97, that would be great.
In VB6 I tried to set a reference to C:\Software\Microsoft\Office97Pro\OFFICE\mso97.dll (path to software - not installed) but that didn't work. I then tried regsvr32 mso97.dll but that gave me the error: mso97.dll was loaded, but the DllRegisterServer entry point was not found.
Anyone know what I need to do to get this to work? Or will I need to install Word 97 on my machine for it to work?
It sounds like you basically want to do as suggested in Writing Automation clients for multiple Office versions but ignoring the advice about using late binding.
The type library involved is MSWORD8.OLB, but I can't recall whether there is any legitimate way to obtain it without Word 97 or an Office 97 Edition including Word. Offhand I'm not sure what the impact of registering this tylepib would have on your Word 2007 installation either, since they may well share many ClassID values.
In the VC++ article PRB: Automation of Office Using #import Can Fail if Multiple Versions of Office Are Installed Microsoft seems to suggest this can be a viable strategy as long as you reference the proper OLB. This is probably less of a problem for VB6 than in C++ because VB6 doesn't use the VC++ #import semantics for locating typelibs. Then again they may be referring to run-time behavior, since the explanation concludes by once more suggesting late binding.
The article WD: How to Obtain the Word for Windows Type Library offers links to the Word 6 and Word 7 typelibs (links may no longer be good) but none for Word 97, which they suggest you obtain by installing Word 97.
In any case it only sounds safe to use the constants, enums, etc. from Word 97 and use late binding for all of your objects. This "half a loaf" is better than nothing. You could still do your initial development with early-bound declarations to geet "Intellisense" assistance, then go back and change all of the early-bound object declarations to late-bound As Object and replacing Set X = New TYPE by the corresponding late-bound CreateObject() call, leaving the actual strong typing as a trailing comment. One could also use conditional compilation #If/#Else blocks to make flipping back to early binding easier later.
Since obtaining MSWORD8.OLB legitimately may be impossible today, you might also consider OFF: "Built-in Constants in Visual Basic for Applications" (WC0993) which offers a download containing VB .BAS modules defining the constants for many old versions of Word and other Office applications. The download link works - as of right now at least!
Since named constants are the primary reason for the typelibs (considering that only late binding is truly safe) this might not be a bad compromise. You can take the .BAS file you need, clean it up (bound to be some warts in there), and even convert it to a custom "Generic Word" TLB containing just those constants and enums with a little effort. For that matter somebody may already have done this work. I'd suggest you try a few searches before writing your own "VB .BAS to ODL/IDL" compiler though.
When adding a reference to your project, look for MS Word x.0 Object Library where x is the version of MS Word you want to work against. I believe you can reference a lower version than Word 2007 (version 12.0). Look for 8.0.
I have an old vb6 app that I'm in charge of maintaining that saves, opens, and prints Word documents to a users computer. The other day when we switched from office 2003 to office 2010, I started to get complaints that the software would no longer open saved reports and print them. Removing Officer 2010 and installing 2003 fixes the problem.
The sub procedure that handles this is all vanilla msdn code and I'm unable to find anything that would tie it to a certain version of Word. My next thought is perhaps its the OLE dll reference. Where/how can I update the VB6 reference to the dll to work with the new version of office?
Any other suggestions would be greatly appreciated.
I'm not sure but as a guess it sounds like you are trying to use early binding. If so this is likely your problem.
There are numerous MS KB articles warning about this over a period of over a decade. Examples:
http://support.microsoft.com/kb/247579
http://support.microsoft.com/kb/245115
In other words: remove all references to any version of Word, declare all of the objects As Object, and use CreateObject() or GetObject() where appropriate instead of Set Obj = New LibName.ClassName.
These KB articles are old now, and the old rules that let you get away with compiling with a reference to Word 95 and still automate Word 2002 don't seem to apply anymore. Besides needing the oldest supported version of Office installed on your dev machine, I suspect upward compatibility was broken beginning in Office 2003.
Your best bet is late binding. The performance penalty is minimal for most programs so the biggest headache is losing IntelliSense.
If you just blindly update the reference, you'll likely break support for Office 2003. if that's not a problem, go for it.
if it is, you'll need to narrow down where in particular, the app is failing. There are some minor differences between revs of the automation model between versions. Not a lot, but they are there.
Most likely, the code is doing something in a way that makes it specific to 2003. MS does a pretty good job of maintaining backwards compat, but they aren't 100%
To answer your question "Where/how can I update the VB6 reference to the dll to work with the new version of office?": You need of course a computer with Office 2010 and VB 6 installed. If you open the project in the VB IDE, you can change the reference to the appropriate Word Library. The references are also noted in the VBP file, e.g. like this
Type=Exe
Reference=*\G{00020905-0000-0000-C000-000000000046}#8.0#409#C:\Program Files\Microsoft Office\OFFICE11\MSWORD.OLB#Microsoft Word 8.0 Object Library
Reference=*\G{00025E01-0000-0000-C000-000000000046}#4.0#0#C:\Program Files\Common Files\Microsoft Shared\DAO\DAO350.DLL#Microsoft DAO 3.51 Object Library
Reference=*\G{420B2830-E718-11CF-893D-00A0C9054228}#1.0#0#C:\WINDOWS\system32\SCRRUN.DLL#Microsoft Scripting Runtime
Then recompile.
Well, and if you are there, you can just start to debug and see, what happens in detail and why the reports fail. There's no way to change the reference without recompiling, if this was your question.
If it's plain vanilla code related to open, save and print, it's hard to imagine something going wrong.
On the other hand - are there any "base files" in Word format, which are used? May be they have an old format (from Office 95, have just seen this lately). Try to open those files manually and see what happens.
I would like to create a report designer that has the same functionality and ease of use as the Visual Studio IDE. The ability to drag controls onto a form, select various subsets of those controls, align left, evenly space, etc.
The only tools I have ever encountered are really bad. Crystal Reports, the MS Access report crapola, ComponentOne, etc. Is there a third party tool that does this right, or do I have to roll my own?
Um, sounds like you want to do ad-hoc reporting. I have never seen one of these done well outside of a COTS product like BusinessObjects Web Intelligence, which I am using right now on one of my projects.
http://www.businessobjects.com/product/catalog/web_intelligence/
I think you'll have to roll your own here.
The problem here is one of balance. Third party reporting tools have to be flexible, open and highly customizable to the whims of every potential user. As a result, these tools end being not usable to a lay person.
That said creating a visual report designer is not a trivial task. So my suggestion would be to distill the user's voice to find the minimal set of functionality (report elements, formatting, etc.) done first in a usable manner... may not be pretty the first time. And then iterate.
I'm working on a similar need and currently evaluating if MS Word with some custom add-ins would get the job done.
Some years ago I used Active Reports from a company called Data Dynamics. It was nice in that it allowed my users to create their own reports - and they loved not having to contact me to create some ad-hoc report. I am sure the product has evolved since 2001, might want to give it a look.
There is an SQL MS Reports Solution. It's called SSRS and you may have heard of it, but what you might not know it there is an OK end user targeted reporting tool. It works especially well if you are using datasets. The reports can be saved as files and run and/or built inside a VS project, within SQL SSRS, or using the free standing tool (i'd start here). They can also be run from a web control. They can export to excel and even PDF I think.
See SQL2008 Tool here - http://www.microsoft.com/downloads/details.aspx?FamilyID=9f783224-9871-4eea-b1d5-f3140a253db6&displaylang=en
More info here - http://en.wikipedia.org/wiki/SQL_Server_Reporting_Services
This is also available in SQL2005 also I believe.