Why don't I have access to all the feedback drop-down options?

I created a quiz in Quizmaker and want to provide feedback by answer rather than by question. It should be easy; I should just be able to select By Answer from the Feedback area in the toolbar. However, when I go to make this change, the option isn't there. It's blanked out and not even visible. There's just a white space where it should be. I don't understand why it's not there an not working. In my quest to fix it, I've uninstalled and reinstalled Articulate Studio and no dice. Any suggestions on how to recover this functionality? I'm having the same issue with the Score section. My only option is the default (By Question) and in some cases I want to score by answer. Help!

12 Replies
Laura Payette

Thanks, Charles. That helps explain part of my issue.

However, I created a question that's multiple response and the feedback option in the toolbar defaulted to none. I want to change it to By Question and there's no option in the drop-down box to do so. It's just blank except for the None option. I know I can include feedback by answer on a m/r question! I just can't figure out what's wrong with my toolbar functionality. Still looking for some help with that.

Ben Riller

Unbelievable that you expect people to change their preferred dpi setting to suit QM (and Engage, I think) to 96 rather than supporting 120 (or other custom) dpi. One purpose of Microsoft offering this choice to users is accessibility. I for one cannot cope at all with 96 on large monitors (which I need for work purposes). More to the point, no other app that I use causes this erratic behaviour.

Surely this is something that requires an urgent fix?! (It certainly doesn't rate as a "feature request"!)

Ben Riller

Hi Brian

Thanks for your quick reply (always a welcome proclivity from the Articulate support people).

I won't submit a feature request, because, as I intimated, this cannot reasonably be argued to be "feature" to be requested by a customer. It is pretty standard (not even "best") practice for software developers and should be one of the things that gets included in early (alpha!) versioning. As I said, I have not experienced any other of my many apps (large and tiny) failing in this area.

It's not as though high-dpi usage is a new thing. It went through its worst anxieties in the mid-noughties and has since 05-06 n pretty generally standard in all development houses, small and large. 

It seems as though your backroom fellows have been remiss in this area and may need to do some urgent homework.


Ben Riller

You could perhaps press them to take a look at this seminal paper from 2001 (yes, 2001!) (And there’s much else, since.)

How to Write High-DPI Applications


Nick Kramer, Microsoft Corporation

March 2001


"...Does your application work on high-density displays? Probably not. The standard computer monitor today has a display of about 96 dots per inch (DPI), and most applications assume that they are running on a 96-DPI display. But that’s an increasingly dangerous assumption.... [[AHEM, this was written ten years ago!]] 

 “…Applications without high-DPI capability will range from ugly to unusable, depending on the application and the DPI. Most applications that have large font support are disproportionate but usable at 130 DPI. At 200 DPI, the same application is unusable. Sometimes the application will be uniformly smaller, but more often some elements will be drawn at the correct size (say, if the application uses DEFAULT_GUI_FONT, which gets bigger as the DPI grows), while other parts shrink..." [etc.]

They could also refer to

How to Ensure That Your Application Displays Properly on High-DPI Displays


Writing High-DPI Win32 Applications


And a series of Tutorials about Writing High-DPI Win32 Applications