Need to use older version of RTF without overwriting the MS Word version
Hi
I have a system that was developed in VB6 (Shortly to be rewritten in VB.NET) which uses rtf documents saved from MS Word 2002 which I scan to isolate certain details and change them. The user now wants to upgrade to MS Word 2010 but this causes problems within my system because it uses a later version of RTF. Is there any way that I can take the .DOC or .DOCX inputs and run them through an earlier version of RTF? I do not mind the fact that it will drop some functionality.
Regards
Mac
You could use DocX to read the data you need directly or possibly down-convert the documents.
You might need to make the DLL COM-visible (DocX source code is available on GitHub) or write a wrapper DLL that is COM-visible so this can be used in VB6.
This approach should save you time when you rewrite the app in VB.NET.
Related
When you export Batch configuration in Kofax 10.2 through UI it generates a cab file.
There a bunch of binary files like dlls in that cab file. That kind of kills an ability to store it in version-control system.
Having those configuration file in version control would allow better/easier code sharing/testing/deployment/automation.
So I have 3 questions:
Is there way to export version-control friendly batch configuration?
Is there way to integrate Kofax with version control directly?
Are there any plans to add this functionality in future versions?
Thanks.
Unfortunately the short answers to all of your questions are No.
Despite the fact that it has no granularity, you should store the whole cab file in source control, since that is what you would use if you needed to restore your configuration to a previous state.
Within the cab file, the primary item that holds the batch configuration is the admin.xml file. If you really felt the need you could extract the contents of the cab file and also store these in source control. If you were to diff versions of the admin xml you may be able to determine context about what changed in the batch class. However you would still only be able to restore the full cab file.
Additionally, you mentioned dlls in the cab file, so I assume that you have Validation Scripts or something similar. Not only the built dlls, but also the source code would be within the cab in folders like Scripts\00000001[DocumentClassName]. So again, keeping the extracted contents in source control might be a good way to be able to diff changes, etc. But you still do need to keep the full cab since that is the only way you can import the batch class configuration.
Everything that Stephen said in his answer, and...
For some of the types of configuration management, version control, and troubleshooting tasks in the Kofax environment, I have found Beyond Compare by Scooter Software to be supremely helpful in comparing the contents of two .cab files and reconciling differences between them.
I'm speaking specifically of comparing cab files containing Kofax batch classes, which also contain the document class information for the document types in the batch class, as well as other things like assigned users, etc.
This will work best if your cab files have only one batch class in each, the same one, e.g., before and after cab snapshots, for the same batch class.
In Beyond Compare (BC) (I'm using the 4.x version), from Windows Explorer you select one .cab file for the left side, and the .cab file you are comparing it to for the right side. BC will show you the files inside each cab file, and as Stephen said, the admin.xml is the one with the details.
You can actually copy XML lines from one side to the other in BC, and save the result, but the real value is in seeing what settings changed between versions of the batch class.
If Kofax had some sort of scriptable automation API for the admin module, that would be amazing and potentially enable many of the capabilities you describe, but if Kofax does have such an API, I am unaware of it. I'm currently running Kofax Capture 10.1.
In Kofax version 11, they did add some features for keeping versions of batch classes automatically for you, so you can audit changes that were made in the admin module. Didn't notice anything about an automation API for the admin module in Kofax 11.
I have to load a .htm file and save it to .xlsx file format by automation using progress? Need a solution to solve this!!
AFAIK there is nothing in Progress that will help you do this. If I had to do this, I'd look to Apache POI, which is capable of creating .xlsx fairly cleanly and has a reasonable learning curve, although it is picky about data coming into it and its error messages are typically obtuse. Using Progress directly, you could parse the .html (painfully), but creating .xlsx yourself is probably unrealistic. So, I'd also hunt around for any tools that can do this directly. Good luck.
What O/S and Progress version are you using?
If the HTML is well-formatted, perhaps you could use XML parsing to assist. I have never tried this, though.
As for writing an Excel document, there are many approaches. If you are running on a Windows box that has Excel on it, there are solutions that allow you to call the Excel libraries from inside of Progress. If you need something portable, your choices are fewer. We use ABL_xks.i, which works under both Linux and Windows. It uses the native libraries under Windows, and produces an Excel XML spreadsheat under Linux.
As I recall, there exists a library that allows you to edit an OpenOffice template (Word or Excel) from within Progress. (I would have to go searching for this, but a good place to start looking might be the OpenEdge Hive). And there several commercial packages (especially report generators) that range from using the OO template technique to full automation of Excel output.
If this doesn't point you in the right direction, fill us in with some more details about what you want to do.
InterWorks has a Workbook SDK as part of its Power Tools for Tableau product. Does anyone know how they are able to do this? The SDK can access a workbook without Tableau Server so I don't think it's the JavaScript or REST API.
A Tableau workbook (.twb) file is in XML format. The structure may change between versions, but is relatively straight forward to follow. Most Tableau file formats are also XML. The formats ending in an x (like .twbx) are zipped directories that contain the XML file along with other files.
This means it is not too tough to read information from these XML files, or even modify them. I've edited them by hand in rare cases. Usually there is a better choice than hacking the XML internals, but you can. Just backup your file first, and don't expect Tableau support to help you if it leads to strange behavior on your workbook.
In addition to the Interworks SDK (which is a COTS product), Chris Gerrard published a free Ruby library for accessing Tableau workbooks https://rubygems.org/gems/twb (or gem install twb) and released the source on github https://github.com/ChrisGerrard/TWB, along with a few (but not all of) the scripts he's written that use the twb classes https://github.com/ChrisGerrard/TableauToolsRuby.
Chris gives some useful examples and scripts on his blog Tableau Friction, including this clever article on automatically documenting the relationships among calculated fields
http://tableaufriction.blogspot.com/2015/02/more-calculated-field-analysis-fields.html
Using twb, you can write simple Ruby scripts easily to look at workbook structure. Since Tableau can change the format when they release new versions of the software, using the SDK or twb Ruby gem could isolate your scripts from changes to the format.
Tableau has also released a Document API that supports a modest number common changes to workbooks - so you can write a script to say, update the connection string on a set of workbooks.
So you have at least four choices:
Use Interworks SDK and tools that come with support, documentation and a price tag.
Use the free open source twb library, and either reuse existing Ruby scripts or develop the ones you need. And hopefully contribute the source if you extend.
Roll your own XML parsing scripts.
Use the Tableau Document API if it supports your use case. https://github.com/tableau/document-api-python
In all cases, do backups and be prepared for some adjustments when Tableau releases a major or minor version update. Patch releases are pretty safe.
I am working in a company who is using TFS'12 for keeping track of PDF versions. The problem is that they are running out of space VERY quickly. I suppose this is because TFS use SQL Server and SQL Server treats every pdf as a BLOB object.
The question is: is it possible to use TFS for doing version control on files that do not contain code (images, pdfs, videos, etc)?
It is quite possible to use TFS for this purpose. Make sure that the space situation is due to increase in data space, not log space.
I have an Excel 2010 Automation project using Microsoft Office Interop library in C#.NET. But now i need to migrate it to work with Open XML SDK 2.0. Any guidelines or suggestions?
OpenXML SDK provides far too many low level access / functions. It consumes some time to master but has huge flexibility.
For starters, use libraries like EPPlus or ExcelPackage. If you have very very large files to process frequently, OpenXML should be best bet.