Doing some projects that involve integration with SharePoint lists and to drive these lists we are planning on using the custom properties of Office documents (word, excel, & even outlook email). We need to include in that Visio drawings as well to populate column data from fields created in the custom properties of the documents.  It's seems that Microsoft has chosen to make Visio the Redheaded Stepchild in the Office Family and not provide 'custom properties' like it does with so many of its others apps (including email pulled out of outlook!).

From where I sit this simply sounds like someone dropping the ball from a strategic standpoint.  Is there a way to enhance the Visio documents to provide this sort of appearance to SharePoint so it might populate the columns as other documents do? Or are we going to be forced to do some kludged solution like put a Visio document inside a word document to populate the columns like we want for our SharePoint Lists?

I checked and even Visio 2013 shares this design shortcoming.  For some reason, the is an apparent conscious decision to leave this functionality out of this member of the Office family and I would like to know why.

Regards,

Ken,

Visio was a standalone and very successful product before Microsoft purchased it and put it under the Office umbrella.

Visio has custom properties at the Document, Page, and Shape level, all are available via automation. It uses a different data model and all that is required is some investment into understanding what it is comprised of. I'd suggest you start over here.

Al,

While I really appreciate the response and the pointer to the additional information. I was / am aware of the history of where Visio came from.  Unless your response is masking a solution buried deep in the chapters 26, 27 and/or appendix A I see little help here.  What I am finding a mystery and virtual conundrum is Microsoft not making some effort to place a wrapper on the data model used by Visio to be consistent with other Office elements so as to be treated the same by Back Office tools such as SharePoint. 

In my case that is exactly the challenge I face.  I want to use Properties (Custom and Standard) to populate columns of a SharePoint List comprised of documents.  These documents include Word, Excel, Outlook email, Visio, and PDF's.  Now admittedly, the PDF is not part of the Office family and in fact produced by a third part but shares the same property attribute that can be used to populate the SharePoint list that Word, Excel, & Outlook Email have.

So my only alternative at this point that I can see would be to drop the Visio document inside a Word document and then into the SharePoint List.  While this would achieve the result it also would add considerably to the overhead and make for a very sloppy solution.  A more elegant solution would be if I could somehow attach the properties to the Visio file without damaging the function of the Visio file. I simply wasn't sure if this had come up or been done before.  Or alternatively perhaps there was a different solution that would achieve the same result.

I want to avoid encasing the Visio document inside a Word document. That to me is a very poor solution. But if it all I have left with at the end of the day I supposed that is what I will be left with.

Al,

I am aware of what you are saying.  I just don't happen to agree with the premise that it is an insurmountable objective for MS to standardize their office app to behave in the same manner from an external standpoint.  From an architectural stand point is screams of a less than stellar job of integration into the suite of products.

I suppose I should mark this thread as being answered and closed.  The answer being a resounding 'no' and closed in that there is no provision, adaptation to provide the fictionally that I'd hoped for.

What we will have to do is what I had assumed to begin with which is to imbed the Visio into another document as a container object and drive the process from that perspective, or write custom code to extract the necessary data for population of the library properties in SharePoint as we desire if we want this to be a truly automated solution and that is precisely what we intent to achieve. 

I do appreciate the feedback.

Regards,

Ken...