Изменено ли развертывание диалоговой графики в GMS3?

Question

Я широко использую графические c элементы в диалогах DM, в основном для визуальной обратной связи. Хотя я успешно использовал их в GMS1 и GMS2, ​​я до сих пор не получил их правильное поведение в GMS3. Интересно, неправильно ли я их разворачиваю. Приведенный ниже пример сценария иллюстрирует мои две основные проблемы: несоответствие между размером элемента graphi c и связанной с ним битовой картой и странное сопоставление контраста (черному) для значений битовой карты 240 или 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();

По крайней мере в GMS 3.4 растровое изображение, кажется, только заполняет верхнюю левую четверть указанного графика c площадь. Однако эта проблема сложна, поскольку наблюдаемое мной поведение, похоже, меняется с параметром масштабирования экрана Windows и конкретной версией Windows. На данный момент, с GMS 3.4 и последним обновлением Win10, я обнаружил, что следующий измененный метод Init предоставляет исправные (хотя и некрасивые) обходные пути:

        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);
        }

Однако я обеспокоен тем, что эти обходные пути могут сломаться в будущем выпуске GMS. Кто-нибудь нашел лучший или более правильный способ развертывания диалоговой графики в GMS3?

Answer 1

Windows10 Масштабирование точек на дюйм для приложений действительно вызывает много проблем с пользовательским интерфейсом. Некоторые из них требуют перезапуска приложения после изменения dpi, но некоторые из них являются «постоянными».

Я бы назвал две проблемы, о которых вы упомянули, как об ошибках, о которых следует сообщать в программном обеспечении Gatan сообщение о проблеме site.

Ваше исправление stati c 'scaling' действительно слишком fr agile, так как точное значение для масштаба должно быть определено для различных настроек dpi дисплея. Я не знаю команду сценария, которая могла бы получить эту информацию на данном этапе.

Что касается замены цвета на прозрачный: если бы мне пришлось угадывать, то это всегда было так, но точный цвет представлял цвет фона в GMS 2, в то время как в GMS 3 его больше нет. Так что, скорее всего, это также упущение / ошибка версии GMS 3, о которой следует сообщать.