...I need to preface this with "I am a total moron when it comes to anything other than basic Word or other Office product features."
I have a large document that is an API reference manual (around 200 pages) and I am updating it every so often as new releases are made available.
One of the problems I've always had is that my very carefully formatted and styled Table of Contents tends to get hosed up every time the page numbers need to update (which seems nonsensical to me considering that they're chained to particular styles in the document and should, therefore, update auto-magically.)
What always seemed to happen when choosing "update fields" is that the entire table would get reformatted.
Well, I found another way to trigger updating the fields in the TOC but simply by clicking in the TOC and pressing F9 which brought up a little dialog that let me specify to ONLY update the page numbers and bingo - updated TOC.
I'm sure this is dumb, and I should have found this 5 minutes in, but just in case there's another one of me out there - here you are my fellow nin-cow-poop (to quote Bugs.)
Monday, June 25, 2012
Word 2010 Table Of Contents nightmare...
Posted by
Hans
0
comments
Labels: Table of Contents, TOC, Word, Word 2010
Saturday, June 16, 2012
C# calling a C++ DLL, things NOT to forget
Whatever you do, no matter how rusty you are at doing this, remember to set the calling convention on your DllImport statements. I spent two hours last night trying to track down a bizarre AMD ATI driver bug in a 3D rendering dll I was writing - it only occured when the platform was x86 and the requested feature level was DirectX 11, all other feature levels worked fine and everything worked fine on x64 from the get go.)
I went to bed frustrated (and tired - it was 1:45AM and I wasn't planning on that last night - lol) and woke up annoyed, and after finding very little mention of the problem on the inter-tubes figured I was doing something stupid (since it is unlikely I'm the one discovering a 'new' problem with an ATI driver and Direct3D.) As usual, assuming I screwed up has paid off in spades.
It turns out that I was suffering some sort of stack corruption that was screwing up the creating of devices and swap chains in DirectX 11 and the root cause was my ASSumption about the default calling convention of a DllImport. I figured it was cdecl, and my C++ dll is sprinkled with __cdecl export definitions; unfortunately, (and here's where I wasn't thinking very well) the default convention is OF COURSE WinAPI.
Once I specified the calling convention my mysterious and bizarro AMD driver issues suddenly vanished, and I have now moved on to more mysterious and problematic bugs.
Posted by
Hans
0
comments
Labels: C#, C++, Calling Conventions, cdecl, Direct3D, DirectX11, Dll, DllImport, WinAPI
Monday, November 7, 2011
Associating execution of Powershell scripts with the default open action in Windows 7
I've been using Powershell a bit lately and finally got to the point where I'm using it so much I want to be able to simply double click on a *.ps1 script file and have Powershell execute it. So, in the interest of creating an internet based reference that I can Google myself when I forget this:
*** Note: Always backup your registry before editing it unless you really like rebuilding things ***
Basically you need to create a default value inside the registry key (if the sequence of keys doesn't exist, create them):
HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell\Open\Command
Leave the value with the name '(Default)', make it of type REG_SZ, and set the data to:
Where "
The sequence "& '%1' " is important.
BTW, I highly recommend that you make sure your Powershell script execution settings are set to require remote scripts to be signed properly.
Posted by
Hans
0
comments
Labels: Powershell, registry
Monday, August 15, 2011
When your favorite Firefox extension gets 'obsoleted' on you...
...you can sometimes get around waiting for the developer of the extension to update it for whatever version of FF you're currently on.
Often, the extension will have an attribute specifying the greatest version of Firefox that it can be used on. This is, of course, a safety mechanism to avoid having a new version of Firefox break the extension and everyone start screaming at the extension developer (which is always a stupid thing to do irrespective of your reasoning) about how their extension is crap/broken/stupid/et cetera.
I have a Firefox extension that I dearly love and for the past few weeks, since I let Firefox update me to version 6.0.* I have been without it. I ***NEED*** my Morning Coffee I tell you.
So, finally getting my lazy a**, I decided to look into this and found a version attribute in the extensions install.rdf file that limited it to 4.0.*. I changed that to 8.0.*, and then started up Firefox and voila - lo and behold morning coffee is on. Thank you God (and Shane Liesegang.)
So, to do this yourself:
1. Find your morning coffee add-on, or download it (it should be a file ending in *.XPI)
2. Unzip it (it is basically a zipped folder)
3. Edit the install.rdf file, changing maxVersion to 8.0.* (or some value matching your current Firefox version or higher (mine says em:maxVersion="8.0.*")
4. Recompress the folder (make sure you are inside the unzipped folder and select all of the items in the root of the directory because many archiving utilities create an extra folder to store your zipped content in when the compress)
5. Change the file extension, if necessary, to *.XIP as this is the default extension extension *chuckle* - your honor, your honor...
Posted by
Hans
0
comments
Labels: Add-Ons, Extensions, Firefox, Morning Coffee
Sunday, May 29, 2011
Did this about 3 months back - Chepe's Monster Burrito Challenge
If you eat it, in any period of time you can muster, you get a t-shirt. Trust me, the t-shirt is NOT worth the effort of eating this behemoth.
By the way, in the picture, her arm is nearly touching the back of the burrito - it isn't a trick of perspective. The thing weighs (supposedly) more than 6 pounds.
The only good things are that it is very tasty (for the first 70 bites or so) and it is cheap - only around $15 if I recall correctly.
I will not be doing this ever again.
Posted by
Hans
0
comments
Labels: Chepe's, food challenge, monster burrito
Friday, May 20, 2011
F**$#&% Java Policy Files
If you have ever had to modify a policy file, let me warn you of a wrinkle that you may run into IF your applet/java code needs to perform an operation that is authorized by the policy file BUT IS CALLED VIA JavaScript.
Guess what folks? Java doesn't trust JavaScript any more (and hasn't intermittently over the past 5 years or so - sometimes trusting, sometimes not) so just because you gave your code a valid policy file grant, any code triggered via JavaScript will run as if being run outside the Java codebase (which in a way it is.) This means that you have two options, one of which is not palatable, and the other can break backwards compatibility in your codebase.
(1)Grant permissions without using the codebase attribute (this is very very bad as your permission change will therefore grant the same permissions to ANY applet that the user runs into.)
(2)Surround the code that needs permissions privileges (and can be called via JavaScript) with a doPrivileged block. The downside to this is that early versions of Java don't support this functionality; ergo you are (probably) forced to go the trusted/signed applet route (not good for many reasons.)
Luckily for me, I only need this functionality inside of a tool that is hosting my Java code, so I can put the non 1.1.8 jdk compliant code in my dynamically loaded adapter class that only ships with the offline tool.
Anyhow, I hope someone else trying to figure this out learns from this.
If your applet needs policy file permissions and your applet will be called from javascript, you must not only grant the applet the permissions in the appropriate fashion but also surround the code that can be triggered via JavaScript with a doPriveleged block. This is because Java's runtime no longer executes javascript with the permissions levels of the applet.
Posted by
Hans
0
comments
Labels: applet, codebase, Java, permissions, policy file, security
Wednesday, April 27, 2011
Skeletal Animation – An overview
Posted by
Hans
3
comments
Labels: COLLADA, skeletal animation
