I want to include a link that refer to an internal embedded document, so click on it will open the document.
If I set the target to an external source (like web url) it works fine:
String linkId = xdoc.getPackagePart().addExternalRelationship("http://www.website.hu", XWPFRelation.HYPERLINK.getRelation()).getId();
CTHyperlink cLink = myParagraph.getCTP().addNewHyperlink();
cLink.setId(linkId);
And that is it, it works fine. I just created an externalrelationship with the target url and relationtype and passed it to the hyperlink.
Now I want to accomplish the same behaviour, but this time hyperlink should point to an internal document which resides in the docx under path word/embeddings/test.docx
//embedded part is the packagepart for the document
String linkId = xdoc.getPackagePart().addRelationship(embeddedPart.getPartName(), TargetMode.INTERNAL, XWPFRelation.DOCUMENT.getRelation()).getId();
CTHyperlink cLink = myParagraph.getCTP().addNewHyperlink();
cLink.setId(linkId);
And this is where dead end comes: clicking on the link (the link popup shows the correct path inside docx) automatically change to path to and external one which points to my filesystem. So if my working directory is in c:\myfile the link to my internal file inside docx 'word/embeddings/test.docx' will be changed to c:/myfile/word/embeddings/test.docx which is wrong behaviour in my opinion.
I have tried to pass different arguments to addRelationShip() like TargetMode.EXTERNAL, WPFRelation.HyperLink..etc, but results the same and due to lack of documentation these are just trial and error.
So how should I refer to an internal document via hyperlinks?
Related
I have created a .CHM file and then when I open it in c# I get the First topic. I want to open it to a specified topic.
This is the code I use right now to open it.
Help.ShowHelp(this, "./Resources/ServerHelp.chm");
I want to be able to open it to a specific topic like Audio. I tried using
Help.ShowHelp(this, "./Resources/ServerHelp.chm", HelpNavigator.Topic, "Audio");
and it showed me page not found. Can i get some Help with my Help please !! :P
This can be achieved by the following steps:
Identify what names the chm uses to refer the internal topics. This is done by
Open the CHM file, and right click in the topic page and select Properties.
The property called: Address (URL) Contains the topic page name at its end.
Here is an example:
mk:#MSITStore:C:\Program%20Files\Silsila%2011\Silsila.chm::/Audio.htm
Here the topic page name is "Audio.htm"
Call the Help.ShowHelp() function with the correct parameters as shown below
Help.ShowHelp(this, "./Resources/Silsila.chm", HelpNavigator.Topic, "Audio.htm");
That should do it. you can fine the topic name of the pages you want using Step 1, and then use Step 2 to open the help file on that page.
The same also works to create a windows shortcut opening a specific page. Use that as "target" command line :
C:\Windows\hh.exe ms-its:[file_name.chm]::[page_name.htm]
If you do not know [page_name]: from the chm help viewer, try to print the target page on a virtual printer like PdfCreator. The output filename automaticaly generated will probably contain [page_mane].
With thanks to sazr for the intial syntax !
I am trying to find the file path of nested links and ran into a problem.
I am interested in the 2nd level, meaning finding the file path of a link inside one of the links in the file that I currently have opened.
My problem is where the reference Type is Overlay, if reference type is Attachment I don't have a problem.
I am also assuming the files are in BIM360 cloud, but I believe I have the same problem if the files were local.
I am able to get the RevitLinkInstance and RevitLinkType object for those links.
However, if I try to use GetLinkDocument() on the RevitLinkInstance I get null, and trying getting the InSessionPath using GetExternalResourceReferences() on the RevitLinkType get me "Autodesk Docs://" and stops there without the real path.
Will appreciate any help including letting me know if this is at all possible.
Thank you,
To my knowlegde it is impossible to get the link within a link through one Document. This is because with Overlay the link is not stored into the Link. That is also why it works with Attachment. Because Revit than makes it a point to store the Link in that file and thus it is part of that Revit file.
What you could do instead is search for the file path of the first link. Then use the file path in the OpenAndActivateDocument(string filepath) method. Repeat the first step to get all RevitLinkInstances of this Document. You can get the needed information from this link, store it in a variable and close the link document.
If an example is needed please let me know.
In cases when two attachments with the same filename are attached to a Notes Document, the second file is renamed internally to something like ATTXXXX. Even if the first filename is deleted and document re-saved, the internal filename remains cryptic.
There doesn't seem to be any way to retrieve the original Filename through back-end functions. I have looked high and low in LS but also in the C++ API, and could find nothing. It seems to be a trick that can only be done in the front-end. I am not sure where the information in the file icon graphic is stored, and whether it is accessible. In simple cases it would be possible to do a rename, I suppose (i.e. there is a single attachment and a single file icon graphic).
Could anybody confirm that this is, indeed a limitation of Notes or is there a cool way to solve this?
This is causing me some headaches whilst processing a large number of documents. My customer has trouble believing that there are some things that can only be done in the front end.
You should be able to get the original filename, even with duplicates.
It is not when the file is attached that the name is changed, it is when you detatch it.
You are probably using the .Name property, try the .Source property of the EmbeddedObject, that should return the original filename.
From the help:
If the NotesEmbeddedObject is an embedded object or object link, this property returns the internal name that Notes uses to refer to the source document.
If the NotesEmbeddedObject is a file attachment, this property returns the file name of the original file.
Syntax
To get: source$ = notesEmbeddedObject.Source
It's in the CD records for the rich text -- you will see it if you use NotesPeek to examine the contents of the rich text item. But I don't think it's accessible through the NotesRichText navigator class, so I'm pretty sure you would have to go the C API and parse through the CD records. Or, the MIDAS Rich Text API can probably get it, but that's third party software. I.e., not free.
Will I be able to identify the name and size of a document that I am trying to upload into a SharePoint 2007 document library using Fiddler2 tool?
Follow these steps:
With Fiddler running, select the relevant entry for upload.aspx.
Switch to 'Inspectors / Headers'
Have a look at 'Entity / Content-Length'
I just did a test and it roughly corresponds with the length of the file. I am not sure if it is a 100% match or if headers etc are counted towards this length as well.
Open the document library in Explorer View
copy & Paste the document
Fiddler->Inspectors->Entirty->content-length
Fiddlet-> Textview -> will be able to see the Name ofthe file.
I am using the Hyperlink / Picture column type within a Document Library.
When entering the hyperlink, I am using a shortened path. However, after exporting this site to an stp, I realized that it was being stored as the full path (it was failing when the stp was used in another Site Collection).
As an example, I entered the following path: /SC/Images1/AdministratorUsers.png
However, when viewing the entered docuemnt library item, I see this path: http://servername:port/SC/Images1/AdministratorUsers.png
How do I get around this limitation?
This is a bug, sharepoint saves only full urls. I circumvent this by storing all css and images etc in the root site(collection)'s style library.
Even a publishing page's pagelayout url is stored as a full url, we had to create a tool to update all references when the site was moved to a new url / server...