问题
I make extensive use of graphic elements in DM dialogs, mainly for visual feedback. Although I have used these successfully in GMS1 and GMS2, I have not yet gotten these to behave correctly in GMS3. I wonder whether I am deploying them incorrectly. The example script below illustrates my two main problems, a mismatch between the size of the graphic element and its associated bit map, and a strange contrast mapping (to black) for bit map values of 240 or RGB(240, 240, 240):
class ModelessDialogWithGraphic : UIFrame
{
Object Init(Object self)
{
TagGroup dialogSpec = DLGCreateDialog("");
TagGroup dialogItems = dialogSpec.DLGGetItems();
Number graphicW = 256;
Number graphicH = graphicW / 4;
Image graphicImage := RealImage("Graphic Image", 4, graphicW, graphicH);
graphicImage = icol;
// Add labeled box with graphic
TagGroup boxSpec = DLGCreateBox("Graphic");
TagGroup boxItems = boxSpec.DLGGetItems();
TagGroup graphicSpec = DLGCreateGraphic(graphicW, graphicH);
graphicSpec.DLGAddBitMap(graphicImage);
boxItems.DLGAddElement(graphicSpec);
dialogItems.DLGAddElement(boxSpec);
return self.super.Init(dialogSpec);
}
}
void main()
{
Object dialog = Alloc(ModelessDialogWithGraphic).Init();
dialog.Display("Dialog Graphic Test");
}
main();
At least in GMS 3.4, the bitmap seems only to fill the top-left quarter of the specified graphic area. However, this issue is complicated because the behavior I observe seems to change with the Windows display scaling option and the particular version of Windows. For now, with GMS 3.4 and the latest Win10 update, I have found the following altered Init method provides serviceable (though ugly) workarounds:
Object Init(Object self)
{
TagGroup dialogSpec = DLGCreateDialog("");
TagGroup dialogItems = dialogSpec.DLGGetItems();
Number graphicW = 256;
Number graphicH = graphicW / 4;
Image graphicImage := RealImage("Graphic Image", 4, graphicW, graphicH);
graphicImage = icol;
graphicImage = (graphicImage == 240) ? 241 : graphicImage
// Add labeled box with graphic
Number scaler = 0.5;
TagGroup boxSpec = DLGCreateBox("Graphic");
TagGroup boxItems = boxSpec.DLGGetItems();
TagGroup graphicSpec = DLGCreateGraphic(scaler * graphicW, scaler * graphicH);
graphicSpec.DLGAddBitMap(graphicImage);
boxItems.DLGAddElement(graphicSpec);
dialogItems.DLGAddElement(boxSpec);
return self.super.Init(dialogSpec);
}
I'm concerned, however, that these workarounds may break in a future GMS release. Has anyone found a better or more correct way to deploy dialog graphics in GMS3?
回答1:
Windows10 dpi scaling for applications is indeed causing a lot of misdrawing UI issues. Some of these require an application restart after dpi change, but some of them are 'permanent'.
I would consider the two issues you've mentioned to be bugs which should be reported at the Gatan software issue reporting site.
Your static 'scaling' fix is indeed too fragile as the exact value for scale needs to be determined for different display dpi settings. I'm not aware of a script command which could get you to this information at this stage.
As for the color-replacement to transparent: If I would have to guess, then this has always been like that but the exact color represented the background-color in GMS 2 whereas it no longer does in GMS 3. So it is likely also an oversight/bug of the GMS 3 version and should be reported.
来源:https://stackoverflow.com/questions/61036091/has-deployment-of-dialog-graphics-changed-in-gms3