Silviu-Marius Ardelean's blog

a software engineer's web log

The Chameleon Pathnames

The title might be as well “When the pathname is not what it has to be”.

The experience of developing plugins for Adobe Acrobat/Reader reserved me different surprises, surprises that made the task more challenging. One of the biggest surprise I had was the impact of the Adobe’s Cloud idea over the Acrobat’ API within Acrobat products. Their feature idea is to keep all the already opened documents within their Cloud in order to make them available to different devices you’re interacting with.

In my case, having interactions with external non-Adobe’s applications, the things complicated when trying to get the file pathname. This option is coming enabled by default.

This is how the Cloud looks like within Acrobat products This is how the Cloud looks like within Acrobat products

Usually, when we are thinking to files path we expect to have something similar to GetFullPathName(). But according to Acrobat SDK’s concept: not every file opened into Acrobat/Reader has to be a local disk file. It may be associated with a stream, a network file, etc.

The reason why I was looking to get the correct file path is that my plugin and others are connecting to a system that expects the local or network file path. So it was needed to find a way to get an usual file path.

The challenge I am talking about has reproduced with an environment activated, having such a file already synchronized in the cloud by using:


But both API’s functions return proper values with non-Cloud files. With a local filename not already uploaded within I got the correct file path with both functions.

So the workaround I was thinking invokes the next steps:

1. Get the file path using ASFileSysDIPathFromPath(). In case your project is a Unicode project don’t forget that the returned type is a char* and you’ll need to encode it to the proper Unicode (UTF-8 in my case).

2. Check if it is a cloud path (starts with


3. Save the file content into a temporary file (ex. C:\Users\Silviu.Ardelean\AppData\Local\Temp\)


4. Provided the temporary file path to the proxy module that expect it to interact with my system.

5. Clean/delete the temporary files on plugin uploading – PluginUnload() callback.

Additional comments
In case your plugins will interact with external non-Adobe’s application most probably you’ll have to do different tricks. Because of the way the Acrobat SDK is designed, without direct support for wchar_t and std::wstring you will need do make different conversions and encoding/decoding (ex. the ATL macros CW2A, CA2W(), functions such MultiByteToWideChar() on Windows, etc).

If you don’t have to interact with external non-Adobe’s applications be confident with Acrobat’s SDK types and data structures. In this way you’ll avoid such conversions.


HTML files generation using XML and XSLT with Microsoft XML DOM API

This short tutorial shows how easy it’s to generate reports in HTML pages using Microsoft XML DOM API together XML and XSLT.

XML (Extensible Markup Language) became a universal standard of encoding data in a format that is both human-readable and machine-readable. It’s widely used in business applications and even Microsoft Office uses it into internal file formats.
XSLT is used for XML documents decoration. Once we have data into a XML files, using the XSLT (Extensible Stylesheet Language Transformations) we can easily generate HTML and xHTML files. XSLT is a W3C recommendation still from 16. November 1999 and in the meantime it was extended with a new version XSLT v2.0.

XSLT uses XPATH to get the XML’s tags information, complete the predefined temples and transform results into a .html document.
Each decent browser has support for XML and XSLT. All we have to do it’s to link two such files (.xml and .xslt) and once we execute the XML file the browser will generate and render our XHTML content.

But in case we are writing non-browser applications the HTML generation becomes a bit complicated in case you are not satisfied with hard-coded solution and want a flexible solution.

Using the Microsoft’s XML Core Services (MSXML) our job became a piece of cake. We focus once over the HTML generator and later in case we want to change something into our look and content we have to deal only with the .xml and .xslt files.

Because of using COM don’t forget proper the calls of CoInitialize() and CoUninitialize().
Here are two samples files generated with the test application using upper method: sample_1, sample_2.

The combination of XML, XSLT and XPATH offers a very flexible way to generate HTML files. With such an approach even native application does not need to change in case we change the HTMLs look. Within the presented case the hard-coded solutions are avoided and most probably a new recompilation is not needed in case we want to change data content (XML) or the look (XSLT).
In case you want to add sophisticated html code (ex. colored, formatted, images, etc.) you need to convert that code into XHTML format before adding data into the .XSLT file.

demo application (889)


Versionable Object’s Serialization using MFC in non Document View applications

Most existing applications operate with data that must be stored and loaded in different times and different locations. The data is stored in text or binary files with a well defined format.
The Problem
Initially, in the first version 1.0, an application operates with data structures that can be stored and loaded. But, next version (2.0) these data structures suffers changes. Some structure’s attributes are added and other could be removed. These things change files format and structure when a new file version is saved.
Question: What happens when you are using an application version 2.0 and you are trying to load old files format (version 1.0)?
Answer: Most cases should cause incompatibility troubles between the current new application and files in old format. This could throw exceptions and the application could have undefined behavior.
That’s why the application must be written in order to be able to open both file versions.
In order to solve the compatibility issue exist many solutions, more or less professional. The recommended solution is the serialization.
The serialization is a write / read object process to/from a persistent storage. Serialization it’s a good choice in order to maintain a good data structure. Many different frameworks offer serialization support. One of these is Microsoft Foundation Classes – MFC.

If we want to use MFC serialization support, we can use a CArchive instance. This object, combined with a CFile instance provides a strong mechanism for objects serialization.

Because, in different applications version, the file suffers significant structure changes we have to use MFC’s serialization concept called Versionable Schema.
Versionable Schema means the using of CArchive class methods GetObjectSchema() and SetObjectSchema() and a constant VERSIONABLE_SCHEMA (that you can find it in afx.h file and has 0x80000000 value) combined with a OR LOGIC operator and the last application version number as a parameter of IMPLEMENT_SERIAL macro.
The GetObjectSchema() method is used in order to detect stored objects version from a file that is loaded in our application. The complement of this method, SetObjectSchema() method, allow us to save the objects version.
Different by the C++ I/O standard streams, the CArchive class is special designed only for objects serialization in binary files.

In order to serialize a class’s objects we have to follow next steps:
1. The class that we want to serialize has to be derived from the abstract class CObject (or other classes derived from CObject).
2. Overwrite CObject’s Serialize() method.
3. Use DECLARE_SERIAL macro in your class declaration.
4. The serializable class has to have a default constructor, without arguments.
5. Use IMPLEMENT_SERIAL macro in the implementation file of serializable class.

More information you can find it here and in links of this page.

But, from these steps until to a complete serialization and versionable application there are few significant steps to follow.
Next, I will present to you a Dialog base sample application that supports serialization and is versionable.

    Sample application – SerAddressBook

Next, I will present to you how you can create an address book application (based on a MFC Dialog application architecture).

Suppose that initially our client requested us an address book that contaions: name, prename, address and phone number. But, once with the mobile phone and Internet area extensions our client needs two new fields for mobile phone number and for email address.
File versions structure

Our application with a file version 2 looks like this:
Application window

Because this is a demo application I kept on my window the possibility to save both version, using two radio buttons.
A good application design helps us if we have new requirements and we have to change the application structure. The code changes have to be done without too many code interactions. Ideally, with add code only.
That’s why, my application classes design looks like this:
Classes Hierarchy

Although Contact class and CAddressBook class are serializable, the objects serialization is implemented into Contact class.

    Contact class

From Contact’s interface class you can observe:
• I derived this class from the abstract CObject;
DECLARE_SERIAL, macro calling;
Serialize()‘s method declaration in order to overwrite the parent class;
• Our class attributes.

The last line represents an “alias” definition for a MFC list definition, used in order to store displayed data. This list is using for Contact object administration.
In the implementation file we declare the IMPLEMENT_SERIAL macro and we are initializing the static variable with our current application version.

Into this declaration you can observe the VERSIOABLE_SCHEMA constant combined on OR logic with 2 (my demo application last version). This, the third macro argument is essential for objects versioning, combined with CArchive::GetObjectSchema() and CArchive::SetObjectSchema().
More details about this constant and it using process or about these methods you can find here.
The implementation of Contacte::Serialize() looks like this:

If CArchive constructor sets store-load flag on CArchive::store (save to file) then the code flow will follow true if’s block and objects data is sending to archive and stored in the file (including file version, too).
When we want to open an existing file, our CArchive’s constructor receives CArcuhive::load flag and enter to else if’s block of Serialize(). Is extracting file version, and after that is loading all Contact objects.

    CAddressBook class

CAddressBook class make the link between interface dialog class (CSerAddressBookDlg) and the serialized class Contact. This class contains a Contact objects list. CAddressBook class is administrating this contact list and is realizing load/store object.

The interface of this class is looking like this:

Into this declaration you can see the existence of a contact list instance (m_cContactsList). This class contains add, update or remove contact methods.

Because our class has to be a serialized method we have to overwrite Serialize() method, the method has to me used by the client class ( in our case the interface class – CSerAddressBookDlg).

Because CArchive class doesn’t provides any method or attribute in order to obtain the objects (I’m counting when I’m loading or storing), I decided to save the objects count into my files. That’s why, if I’m storing, I call next line:

Same story, for file version, before starting Contact objects serialization:

Then, into a while loop I’m iterating over the contact list. I am serializing the data and I’m storing to my new file.
If I load a file from disk (else branch) then I follow next steps:
• I’m cleaning contact list;
• Get the objects count;
• Get file version and serialize all objects for load;
• Add all data to my Contact object list;

    CSerAddressBookDlg – The application interface class

Once we have implemented this serialization mechanism the using of this one into our application became very easy.

For instance, when the user wants to save into a file all he’s new data, he will call next method:

As you can see, I have a CFile object that I’m using it, combined with a CArchive instance, for data storing to a file. Although my local CArchive instance receive as a first parameter the address of the file handler and the store flag CArchive::store.
Next I call CAddressBook::Serialize() method and I’m closing the store operation.

Loading file method, based on my Contact serialization mechanism looks like this:

As you can see, I am creating a local CFile object, needed for reading operation. Although, I’m creating a local CArchive instance that received as constructor parameter the file handler address with CArchive::load flag.
Then, I’m calling CAddressBook::Serialize() method. Is entering on else branch and finally we are disconnected the object from file.
The last line contains PopulateList() call and is my populate list method. It populates my list control (a CListCtrl instance) with the file loaded data in order to display it into our dialog.

The MFC’s Document View architecture offers complete serialization support. Each MDI/SDI application contains default serialization support. My demo solution presented is an adapted serialization version for dialog base applications.

Download demo application: SerAddressBook (Visual C++ 2005 project)