For the Illustrator side of the question: learn about symbols.   E.g. create your hand shape and a background. Select both, and add them as one symbol in the Symbols palette. Duplicate then means placing another instance of the symbol.   The interesting part of it - you can use the direct selection tool on any part of one placed instance, in our example that would be either the hand shape or the background, and modify / override them in the appearance panel. Different color, show hide that part, or apply any effect such as transform.   For example before UI became boring "clean", we had multiple shades of icons (for dark .. light UI), multiple scalings (normal, hidpi Windows 150% and Mac 200%), and a mouse-over version with colorful accents to better stand out. That would be 24 copies of the same icon, at different scales and few appearance tweaks. ... View more

Get the panel via IDialog::GetDialogPanel, e.g. for Resize() For moving, I used IDialog::SetDialogPositioningAlgorithm(IDialog::kAutoCenter); If you need non-center, dive into the header comments.   I leave palette panel positions to the user, as they are determined by the holding palettes anyway. You can arrange these palettes and groups e.g. docked to some screen margin.   For a large set of panels I added a menu to some Window submenu to collect them into a new palette with tab group, stacked etc. rather than the random initial group. Also doing that from an Initializer for startup once after installation.   Not sure about actual position, but if you find nothing better have a look at the top of PaletteRef.h and GetOWLControl() ... View more

I guess your translation is wrong: Changes were applied to styles and/or named grids. Named grids are a concept of Japanese typography, they can also specify a font.   The "Font Usage Dialog" (original name), later "Find Fonts" or "Find/Change Fonts" reports fonts as they are used with text in the document. If you replace fonts, you'd change with local overrides. This is where it works best.   As an afterthought, in western versions the checkbox below enables that you also apply the changes to character styles and character styles. This is more complicated than you initially think, as fonts are independently specified with the two attributes "Font Family" and "Font Style" and the used font is resolved from their combination.   For example there are ways to incompletely specify only one of the attributes. Create a new character style, and use only the font style dropdown to choose "extra condensed light". You can apply the character style to text using Tahoma via the paragraph style, Tahoma (on my system) has only Regular and Bold. As the combination is not backed by an actual font file, you get a "missing font" even though it never existed.   The program behind the checkbox can only deal with cases where both family and style attribute are specified. It  will fail with the lonely extra condensed italic of cstyle4, because that could also be applied in other places where it makes more sense.   So the dialog mentions that some styles were touched, better verify your entire document. ... View more

Most of the time, Font families (fonts with the same family name) are differentiated by type. A few InDesign versions ago the types were even shown as icons in the Find Fonts dialog, now you have to use "More Info".     Lesser known, there are multiple "OpenType" types, showing the same [otf] suffix and the same icon, but they have a different type for matching. In scripting you can see them:   For this reason (types are relevant) you can come across multiple font families with the same family name, which is already known as bad and confusing the font subsystem thus better avoided, and even multiple [otf] of them. There are some more reasons for mismatches in font family - such as native names (discussed below).   This is the easy part. Under certain circumstances a font is identified by postscript name rather than by combination of font family, type and font style. Could be the placed PDFs where name+style are lost, or a copy-paste from Illustrator, where only the postscript name is known. When you import Word texts, they can also specify fonts never known to your system, I haven't looked what exactly happens then.   Anyway in these cases InDesign tries to substitute (one of the multiple font status values). Most of the time with Latin fonts it ends up at the default font (Myriad) but there is also a mechanism to list font families with "same name", and the found font might spill over. For inconsistency sake, dependent on the program one approach is taken or the other. For example a glyph might be found by the more forgiving composer and rendered accordingly a decade later from composer output, but the missing font highlighter might disagree.   The font lookup mechanism also differentiates between font managers - a font is less likely to get found with the document fonts folder even when it should along the mechanisms mentioned above, so sometimes it is suggested here in the forum to avoid document fonts.   Other criteria come with the font style, e.g. when you have the correct Arial around but the particular semi-bold is only in the other Arial … A font style might also spill over, within the family or across types, e.g. you specify Italic and get Kursiv, Regular for Roman. There is another mechanism that matches beyond the style name, and so forth.   All of these could explain why a Arial TTF specified in a legacy document could end up showing one Arial OTF that might happen to exist on your machine, even if you never used the OTF and the [Regular] font style is or isn't supported by the OTF font family.   Back to your screenshot - could be the paragraph style editor - which is also adding to the confusion. For example when you choose a named font style for a variable font, the font style name will display different from the font menu.   Font families and styles can also have multiple native names, displayed according to the system script if it is not Latin. Not sure why you show a pstyle with that GBK font while the question is about Arial, is that the chinese native name for Arial? If so, could be there is a mismatch in native name between the original Arial and your current one?   Otherwise, was Arial substituted in that pstyle and we're seeing the result? Both font family and font style are surrounded by [], which to me indicates something is missing for both. As we don't see the language from the following dialog page, and GBK is about a specific character set, maybe you have a mismatch there, and the language setting forced the GBK font?   I don't know enough about CJK typography, also for lack of example documents, so forgive any speculation errors. ... View more

Differences: kBindNone large nudge = 0 upper bounds = 100 notify keystrokes = false   Plenty speculation ahead:   My guess is the notify keystrokes flag. kTrue is rare in the SDK examples, and I doubt it is intentional for kSpellAlternativeEditBoxID. Could be the key strokes are absorbed with this flag. Given the (NEW) comment, I assume you copied it from kPDFVTUIDataSourceFileTextWidgetID or kWatermarkUIEditBoxWidgetID. Have you tried with false as I already suggested above?   Otherwise it could be some extra setup code, maybe using a private Drover call. Once upon a time IControlView had a getter for the SysControl / HWND so we could look at the Windows side, but that's gone. If I were desperate I'd try Windows API such as EnumChildWindows() and dig deeper from there.   If you only need the key strokes to update a related display, you could also watch InDesign's events. To learn about focus / blur, observe your kMyeditboxWidgetID for protocol IID_IEVENTHANDLER, message is kEditBoxGetKeyFocusMessage or kEditBoxGiveUpKeyFocusMessage. Between those, register/unregister an IEventWatcher at IEventDispatcher. Works at least here on the Mac.   There is also a very old "filter" programming pattern to subclass the boss class, move the event handler implementation to another IID (any of yours will do) and provide your own event handler that passes on most calls. Somewhere deep in the SDK it is mentioned that event handlers are discouraged, so you better also stay away from that.   ... View more

app.modalState just confirms that your handler is triggered when it is limited in its actions. You have to rewrite your code, avoiding what causes the problem. Find the exact statement, then think of alternative ways. E.g. if it is that itemByName, do you really need it?   Using debug output via $.writeln, or writing to a log file are means to get closer, as you found that alert() was interfering with the problem. It does not solve the problem itself. If you don't know how to use a debugger please open a separate thread or ask any AI .   Your main problem as of now appears to be the new New Document dialog, where the event listener is triggered too early - comparing to the legacy New Document dialog. If you insist on using that approach, file a bug at uservoice and wait until it is hopefully fixed.   > I tried adding the listener to the app but it seemed to give the same result.   As we're talking about multiple listeners here, which one was added to the app? Did you remove the others? Following my suggestion using a single event handler (your hasBeenFired) at the application that takes advantage of bubbling, rather than one at each document, you should have eliminated the need of a handler for AFTER_OPEN whose only purpose is to install those individual document event handlers.    ... View more