A sticking point re: carets
June 16, 2011 9:19 PM Subscribe
The "caret" or "insertion point" is the blinking " | " symbol that indicates where typed text will appear. Does anyone know how to modify it?
In MS Word, when italics are in effect such that the next character you type will be italicized, the caret is italicized, too.
Ideally, I'd like to replicate this functionality for:
Bold: wider caret
Underline: underlined caret
Color text: caret of corresponding color
And ideally, I'd like to do this in applications other than Word.
I realize that all this may be a lot to ask, though, and I'd be content if someone could point me to any means of modifying the caret's shape/size/color in Word or more generally.
If necessary, I'd feel comfortable working in Autohotkey and marginally competent working in Python or a couple older languages.
Thanks in advance!
In MS Word, when italics are in effect such that the next character you type will be italicized, the caret is italicized, too.
Ideally, I'd like to replicate this functionality for:
Bold: wider caret
Underline: underlined caret
Color text: caret of corresponding color
And ideally, I'd like to do this in applications other than Word.
I realize that all this may be a lot to ask, though, and I'd be content if someone could point me to any means of modifying the caret's shape/size/color in Word or more generally.
If necessary, I'd feel comfortable working in Autohotkey and marginally competent working in Python or a couple older languages.
Thanks in advance!
Yeah, it would take a lot of very messy reverse engineering, and it would be very brittle. The good news is that most applications use the MS Common Controls so you'd only have to reverse engineer that (but there are a million different versions of comctl32.dll however, so this would still be a major pain) for it to affect most applications. However Word is not an application that uses the common controls, it almost assuredly implements everything from scratch, so even if you went though all that trouble it would not be applicable to Word. You'd have to start over and reverse engineer Word, which would not be applicable to other applications, aside from COM embeddings of Word documents.
posted by Rhomboid at 11:02 PM on June 16, 2011 [1 favorite]
posted by Rhomboid at 11:02 PM on June 16, 2011 [1 favorite]
What about OpenOffice? There's a chance you could offer a bounty for someone who knows its codebase to implement this.
posted by Busy Old Fool at 12:05 AM on June 17, 2011
posted by Busy Old Fool at 12:05 AM on June 17, 2011
Response by poster: Eh, it was a beautiful dream. Thanks guys.
Busy Old Fool, OpenOffice is a good thought, but my employer needs for us all to use MS Word so we can share documents systematically. For my own purposes, then, I'll call this a lost cause.
posted by foursentences at 4:00 AM on June 17, 2011
Busy Old Fool, OpenOffice is a good thought, but my employer needs for us all to use MS Word so we can share documents systematically. For my own purposes, then, I'll call this a lost cause.
posted by foursentences at 4:00 AM on June 17, 2011
This could be a fun side project... I don't know if this would work, but off the top of my head, I'd try the following (using .NET) :
1. Create an automatic service that monitors running processes looking for winword.exe.
2. When the process is found, hook into the application using the PrimaryInteropAssemblies.
3. As font styles change, use the CreateCaret win32 API to assign to the Window containing the edit region.
You could probably spend a day or two to determine if it's at all feasible and then make run with it or kill it from there...
Actually, thinking about it more, you should be able to call the win32 API from a macro in Word... You might be able to circumvent #1 and #2 above and just make everyone install and use the same Word template that contains the macro executing #3.
Like I said, don't know if it'll work, but that's the approach I'd take.
posted by Jacob G at 7:06 AM on June 17, 2011 [1 favorite]
1. Create an automatic service that monitors running processes looking for winword.exe.
2. When the process is found, hook into the application using the PrimaryInteropAssemblies.
3. As font styles change, use the CreateCaret win32 API to assign to the Window containing the edit region.
You could probably spend a day or two to determine if it's at all feasible and then make run with it or kill it from there...
Actually, thinking about it more, you should be able to call the win32 API from a macro in Word... You might be able to circumvent #1 and #2 above and just make everyone install and use the same Word template that contains the macro executing #3.
Like I said, don't know if it'll work, but that's the approach I'd take.
posted by Jacob G at 7:06 AM on June 17, 2011 [1 favorite]
my employer needs for us all to use MS Word so we can share documents systematically
Word 2010 can both save and open .odt files, is set up as the default handler for .odt files on installation, and does a much better job of not breaking table and other formats than OOo's inbuilt .doc/.docx converter ever did. If your worksite has Windows 7 (which is even better at hiding filetypes than XP was) and Office 2010, you could probably just use LibreOffice on your own workstation and nobody would even notice for years and years.
If it's good enough for NATO, it's good enough for you :-)
posted by flabdablet at 8:49 AM on June 17, 2011
Word 2010 can both save and open .odt files, is set up as the default handler for .odt files on installation, and does a much better job of not breaking table and other formats than OOo's inbuilt .doc/.docx converter ever did. If your worksite has Windows 7 (which is even better at hiding filetypes than XP was) and Office 2010, you could probably just use LibreOffice on your own workstation and nobody would even notice for years and years.
If it's good enough for NATO, it's good enough for you :-)
posted by flabdablet at 8:49 AM on June 17, 2011
Response by poster: Marked as best answer because it looks extremely useful to the next person who may have this question, but for my own purposes this has started to look like very-high-hanging-fruit.
Flabdablet, tempting, but since all our files sit on a firmwide directory and are accessed communally, I doubt I'd be able or permitted to hide their extensions. Thanks though.
posted by foursentences at 2:41 AM on June 18, 2011
Flabdablet, tempting, but since all our files sit on a firmwide directory and are accessed communally, I doubt I'd be able or permitted to hide their extensions. Thanks though.
posted by foursentences at 2:41 AM on June 18, 2011
Best answer: Jacob G's solution won't work. Word owns the painting of the caret. Just fyi.
posted by kthxbi at 9:38 PM on June 18, 2011 [1 favorite]
posted by kthxbi at 9:38 PM on June 18, 2011 [1 favorite]
So of course I was kidding, but the point is that you don't need to hide filename extensions; it's what Windows does by default to extensions it has a registered default handling app for.
Any windows opened in "details" view will of course have a "type" column that will list your .odt files as "Open Document Text" rather than "Microsoft Word Document", but since the Office 2010 install will have registered Word as the default handler for .odt, the icons for all those files will have Word's logo and that will be enough to stop anybody actually looking at the listed type before successfully opening the thing with a double-click.
Only way you'd get busted is if there was a workstation somewhere in your org that still has a pre-2010 version of MS Office installed. On that workstation, Windows would then have no registered handler for .odt files, and they'd show up with an unfamiliar icon and their complete filename including extension.
posted by flabdablet at 9:50 PM on June 18, 2011
Any windows opened in "details" view will of course have a "type" column that will list your .odt files as "Open Document Text" rather than "Microsoft Word Document", but since the Office 2010 install will have registered Word as the default handler for .odt, the icons for all those files will have Word's logo and that will be enough to stop anybody actually looking at the listed type before successfully opening the thing with a double-click.
Only way you'd get busted is if there was a workstation somewhere in your org that still has a pre-2010 version of MS Office installed. On that workstation, Windows would then have no registered handler for .odt files, and they'd show up with an unfamiliar icon and their complete filename including extension.
posted by flabdablet at 9:50 PM on June 18, 2011
Best answer: kthxbi - Good to know. Learning that, I'd probably get the handle of the text control in MSWord, subclass it with something like NativeWindow and then inspect the WM_PAINT messages to see if there was something obvious in that world...
But yeah, definitely more trouble than it appears to be worth.
I'd send a feature request to the Office Team and maybe it'll be in the next version :-)
posted by Jacob G at 5:38 AM on June 19, 2011
But yeah, definitely more trouble than it appears to be worth.
I'd send a feature request to the Office Team and maybe it'll be in the next version :-)
posted by Jacob G at 5:38 AM on June 19, 2011
Response by poster: Feature requested. (Flabdablet, that sounds useful for many, but my firm uses a complex system of Word plug-ins, and a file-sharing system that is integrated into everybody's copy of Word, all of which it would have to be compatible with. I don't know for sure that ODT files couldn't be made to work, but I do suspect I'd be fired if due to my having used an ODT a partner became unable to access a critical file at a critical moment. :) )
posted by foursentences at 7:23 AM on June 19, 2011
posted by foursentences at 7:23 AM on June 19, 2011
« Older unique ideas for collected bottle caps? | Had there been one more Beatles album, what songs... Newer »
This thread is closed to new comments.
You need to know the internal state of an arbitrary application (does it think you're in bold mode, etc.) and alter the text cursor appropriately. For arbitrary app, where in memory does it store its current "next character typed" state? Does it store it at all? Maybe it stores the state of the current paragraph/node instead. Regardless, you can't (without lots of reverse engineering) figure that out.
posted by orthogonality at 9:41 PM on June 16, 2011 [2 favorites]