About one year ago I developed an app that, among other things, had to select parts of word documents and let them blink... just one line like this
Selection.Range.Font.Animation = MSWord.WdAnimation.wdAnimationBlinkingBackground;
The app worked pretty: if you open those docm documents (they have some macro inside) you can see some part blinking...
Now my customer tried it on a brand new laptop using Office 2013 and, surprise, when you open same word documents blinking effect is missing.
Is there a known reason for this?
Is there a way I can solve it?
According to MSDN, the WdAnimation enumeration has been deprecated:
This object, member, or enumeration is deprecated and is not intended
to be used in your code.
I can't find any other reference as to why it was dropped, or suggested replacement.
As a workaround, I just changed the background color. Non-blinking.
Related
Years ago, I wrote a small app in itext2 to gather reports on a weekly basis and concatenate them into one PDF. The app used com.lowagie.text.pdf.PdfCopy to copy and merge the PDFs. And it worked fine. Performed exactly as expected.
A few weeks ago I looked into migrating the application to itex7. To that end, I used the copyPagesTo method of com.itextpdf.kernel.pdf.PdfDocument. When run on the same file set, this produces warnings like:
WARN PdfNameTree - Name "section.1" already exists in the name tree; old value will be replaced by the new one.
When I click on the link to "section.1" in the first document of the merged PDF, I am taken to "section.1" of the last document. Not what I expected and not what happens when using the itext2 app. In the PDF's produced by itext2, if I click on the link to "section.1" of the first document in the combined PDF, I am taken to section 1 of the first document.
There is a hint in Javadocs for copyPagesTo saying
If outlines destination names are the same in different documents, all
such outlines will lead to a single location in the resultant
document. In this case iText will log a warning. This can be avoided
by renaming destinations names in the source document.
There is however, no explanation of how this should be done. I find it odd that this should be necessary in itext7, although it wasn't in itext2.
Is there a simple way to get around his problem?
I've also tried the Sejda desktop app and it produces correct results, but I would prefer to automate the process through a batch script.
My guess is iText 2 didn't even know it might be a problem.
If iText can't deduplicate destination names, the procedure is roughly:
Follow /Catalog -> /Names -> /Dests in each document to find the destination name tree.
Deduplicate the names, by adding suffixes. Remember that a name with a suffix added might be equal to an existing name in the same or another document. Be careful!
Now you can rewrite the destination name trees. Since you have only used suffixes, you can do this in place - the lexicographic ordering of the names is unaltered so the search tree structure is not broken.
Now, rewrite destination links in each PDF for the new names. For example any dictionary entry with key /Dest, or any /D in a /GoTo action.
Now, after all this preprocessing, the files will merge without name clashes.
(I know all this because I've just implemented it for my own PDF software. It's slightly hairy stuff, but not intractable.)
If you like, I can provide a devel version of cpdf with this functionality, if you would like to test it.
I'm working on a Pug template in VS Code and whenever I try to use the emmet abbreviation input:text (or any input for that matter), it resolves to input#(type="text", name="").
It's not the end of the world, but it's driving me crazy, and I can't figure out why it's doing so or how to change it.
I guess my question is: is there any way to change this behavior or any place that I can draw attention to this?
The problem is the treatment of the attributes id and class for indent-based syntaxes (Slim, Pug, etc.).
For some reason it removes the attribute from its current position and pushes to the front the strings # for id and . for class.
This is controlled with 2 regex statements near line 3297 in
C:\Program Files\Microsoft.VS.Code\resources\app\extensions\emmet\node_modules\vscode-emmet-helper\out\expand\expand-full.js
Change
const reId = /^id$/i;
const reClass = /^class$/i;
to
const reId = /^Xid$/i;
const reClass = /^Xclass$/i;
You must also remove the cached version of this file in the directory
C:\Users\__username__\AppData\Roaming\Code\CachedData\__some_hex_value__
Restart VSC and it should work.
For linux systems you have to find the location of these files.
I finally understand why this is happening, and that my confusion was basically a misunderstanding of proper form creation.
All text inputs should have an id associated with them, so Emmet is expecting an ID in the shorthand. So this:
input:text#user
resolves to
input#user(type="text", name="")
Which works great! Too bad it took me months of confusion to I realized how daft I am!
I have been working on creating appointments from Powershell in Outlook. Everything seems to be working with the exception of being able to set the appointment.RTFBODY. It looks like it is stored as a byte array, but despite my best efforts and many attempts I have been unable to set it. Any suggestions would be much appreciated.
http://pastebin.com/kQvGfNRS
Edit: I was able to find what could be a similar issue. https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5dba0d12-94e8-47a5-b082-93d3693e2a47/cant-set-the-rtfbody-of-an-appointmentitem
"I assume you add a wrong version reference. If you add Microsoft.Office.Interop.Outlook 12.0, I could reproduce your issue. I suggest you remove this reference, and add Microsoft.Office.Interop.Outlook 14.0."
Also found this: Outlook AppointmentItem - How do I programmatically add RTF to its Body?
from the link in your question - "it is just a known problem in OOM - setting the RtfBody property using early binding works. Setting through IDispatch::GetIDsIfNames / Invoke does not."
Powershell always uses late bindings (i.e. you cannot declare a variable as an instance of a particular object. e.g. AppointmentItem).
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
We are facing an error of "This method or property is not available because the clipboard is empty or not valid" in one of our Lotus Notes applications. The code basically opens a document, selects all the text, copies it and then pastes it in MS Word document. It does this continuously for a bunch of documents. I found this link which basically suggests adding Application.CutCopyMode = False to the code to resolve the issue.
I need to know can this property be accessed and set via UI for MS Word?
In the example you reference, that Keyword is actually part of the Excel object model, not the Word object model. So you are unlikely to find it in Word's UI. Perhaps you are doing something with Excel as well, or perhaps it is a keyword in the relevant Lotus object model as well?
[
The OP mentioned a link, http://www.tech-archive.net/Archive/Word/microsoft.public.word.vba.general/2007-06/msg00446.html
that suggested changing variables names, but that that did not work.
The linked article also suggests "sleeping for a few milliseconds between copying and pasting"
]