Баг - это неустранимая ошибка программы, заложенная еще на этапе ее разработки. Поэтому баг одинаково проявляется на всех копиях программы и у всех пользователей. В отличие от глюка, который является, если можно так выразиться, "пропадающим эффектом" и зависит скорее от ошибок операционной системы данного пользователя. А есть еще зихер, зихерок - но это уже результат ошибки, которую допустил сам пользователь программы, то есть мы с вами.

Но хватит определений. Теперь поговорим о конкретных багах и о том, как с этим жить. Баг ведь на то и баг, что устранить его невозможно - сделать это могут только разработчики программы (да и то, если их поставить об этом в известность, так как зачастую некоторые баги кочуют из версии в версию). Зато некоторые баги можно обойти другими средствами. Обо всём этом и поговорим. Итак,

Суть проблемы. Это действительно баг номер один, потому-что был и остается во всех версиях программы (во всяком случае, с версии 4.8, с которой я начинал). Причем, прописная буква "Я" вводится без проблем, а вот строчная не хочет ни в какую.

Специалисты говорят, что это связано с некоей "проблемой 255-го символа". Хотя лично мне, дилетанту, не понятно, какая разница между 255-м символом и каким-либо еще. Ну им, программистам, виднее. Кстати - наконец-то! - разработчики в курсе этой проблемы и обещают устранить её в следующей версии. Вот только ждать ее нам придется, наверное, целый год...

Понятно, что банный баг делает практически невозможным использование Эдитбокса в элементах программы, где пользователю предстоит вводить русский текст.

Что делать? Вводить русский текст только прописными буквами Раньше я именно так и делал, ибо не было другого выхода. Но все неудобства этого "выхода" налицо: и необходимость предупреждать пользователя о включении клавиши Caps Lock, и получение текста в виде заглавных букв...

Впрочем, есть и другое решение - использовать вместо стандартного Эдитбокса какой-нибудь плагин. Их можно найти в достаточном количестве в интернете. Я же предлагаю вам использовать не плагины, а модули для ММВ, которые написал член нашего клуба Rush. Его модули Editbox.dll и Textbox.dll имеют маленький размер и при этом могут выполнять кучу дополнительных функций.

Различие их заключается в том, что модуль Editbox.dll предназначен для введения только однострочного текста, а модуль Textbox.dll имеет несколько больший набор команд. Кстати сказать, аналога этому модулю в ММВ нет - ведь в Эдитбокс можно вводить только строку текста. И при необходимости ввода большего количества текста вам бы пришлось вставлять в проект внедренный блокнот.

Но есть и некоторые недостатки использования этих модулей. Например, в отличие от стандартного Эдитбокса введенный текст не передается автоматически в переменную. Также не запускается автоматически скрипт при изменении текстового содержимого в модулях. Однако - жить можно

Суть проблемы. Начинающего пользователя ждёт еще одно разочарование - вставленная в проект анимированная картинка (объект AniGif) воспроизводится отвратительно: большая часть изображения оказывается "обтравленной" и как бы пропадает. Причем, никакие действия с опциями (с прозорачностью) положительных результатов не дают.

Правда, далеко не все gif-файлы отображаются некорректно. Полно и таких, которые в ММВ проекте ведут себя покладисто Причём, попытки выявить какую-либо закономерность в том, от чего зависит правильное воспроизведение gif, ни к чему не привели. Например, если предположить, что плохо воспроизводятся картинки, изображающие трехмерность (и в самом деле, содержание таких gif-файлов больше, как больше и их размер), то почему тогда в проекте совершенно правильно отображается, например, вот эта картинка:

Или можно предположить, что некорректно воспроизводятся картинки с большой динамичностью и быстрой сменой кадров... Тоже нет. Вот эта анимашка (вставьте ее в проект и убедитесь сами) воспроизводится просто великолепно:

Возможно, что проблемы как-то связаны со способом создания gif-файла и с тем, в какой программе его делали. Во всяком случае, все анимашки, которые я сделал в программе Adobe ImageReady CS, в проекте ММВ ведут себя ужасно...

Что делать? Ну а что делать? Не отказаться же от использования gif в проекте? Можно, конечно, вместо него использовать flash, но не все владеют этой технологией, да и с флешками тоже есть свои проблемы...

Попробуйте экспериментировать, возможно найдете какую-то закономерность, объясняющую, почему ММВ "не любит" некоторые gif-файлы. А пока приведу два способа, которые могут выручить в некоторых (но только в некоторых!) случаях.

Первый способ. Если основная часть gif-картинки статична, а изменяется только небольшая ее часть, можно попробовать подложить под объект AniGif объект Bitmap, изображающий собой неизменяемую часть картинки. Этот способ выручил меня, в частности, с размещением своего логотипа в проектах (скачайте и посмотрите).

Второй способ. Если gif-картинка будет лежать у вас все время в одном и том же месте проекта, и вы не собираетесь двигать ее во время работы пользователя с вашей программой, то можно вставить gif-картинку в веб-страничку, а ее уже разместить в проекте в качестве объекта Browser. При этом лучше внедрить в проект оба файла - и html, и gif, а при вставке картинки в веб-страничку размещать ее в том же каталоге, где сама веб-страничка.

При таком способе придется маскировать часть объекта Browser при помощи прямоугольников или битмапов, что и накладывает некоторые ограничения на использование данного способа. Вобщем, возьмите пример и сами посмотрите, что к чему.

Нужно отметить, что проблемы с анимированным gif начались в ММВ, начиная с версии 4.9.5. В версиях 4.8 и 4.9.0.1 с этим всё было нормально.

Суть проблемы. В 497-й версии ММВ, как выяснилось, нельзя ввести дробные числовые переменные в EditBox. Точнее, ввести-то можно, а вот программа их воспринимает как целые числа... Поэтому при числовых вычислениях значения, введенные в эдитбоксы как дробные числа, программа будет использовать как целые числа, нагло отбрасывая дробную часть.

Видимо, проблема начинается уже с самого эдитбокса, так как если просто "изъять" из него введенную числовую переменную, то окажется, что дробной части у нее УЖЕ нет. Проверьте это сами. Создайте в проекте три объекта: Editbox, простой текстовый объект Text и простую текстовую кнопку. В объекте Editbox тип переменной выберите "Плавающую" и назовите эту переменную N. В скрипте кнопки напишите:

DisplayValue("Text","N")

Запустите и проверьте. Введите дробное число (внимание: вместо запятой в дробных числах буржуи пишут точку!) и нажмите кнопку. Вы увидите, что вывелась только ЦЕЛАЯ ЧАСТЬ переменной, а дробная игнорирована.

Что делать? Бороться с этим багом будем следующим образом. Раз эдитбокс теперь не воспринимает дробные числа, то будем вводить туда значения не как числовые переменные, а как строковые, с последующим преобразованием их в числовые с помощью команды VAL().

То есть, если, например, нужно сложить два числа x1 и x2, то в эдитбоксы будут вводиться не числа, а СТРОКОВЫЕ ПЕРЕМЕННЫЕ x1$ и x2$. А сам скрипт сложения будет выглядеть так:

y = VAL(x1$)+VAL(x2$)

Либо используйте ММВ версии 4.9.6 и 4.9.6.2, когда это возможно. В них описанного бага не существовало.

Суть проблемы. Еще один неприятный (весьма неприятный!) баг, появившийся только в версии 4.9.7. Теперь скомпилированное приложение нельзя сделать компонентом рабочего стола. То есть если вы выбрали в настройках проекта этот пункт - "Компонент рабочего стола" ("Windows Desktop Component style"), то после компиляции проект вовсе не окажется этим самым "компонентом". А будет вести себя как обычное приложение.

Если вы не в курсе, что такое "Компонент рабочего стола", объясню: в случае выбора этой опции ваше приложение после компиляции (да и при проверке по F5) будет появляться на рабочем столе, ниже всех остальных окон, и никогда его окно не поднимется выше обоев. Кроме того, иконка приложения при запуске НЕ ПОЯВЛЯЕТСЯ на панели задач, а после сворачивания программа и вовсе пропадает, после чего найти ее можно только в списке процессов.

Данная опция была выбрана мной, в частности, для своей программы StopPC. И теперь вполне очевидно, что сделать следующую версию этой программы на ММВ 4.9.7 я не смогу.

Что делать? Делать нечего совершенно. Когда вам нужен такой стиль приложения, создавайте его на ММВ версии 4.9.6.2...

Суть проблемы. При использовании команды PrintRect() изображение выводится на принтер непропорциональным - искажаются либо ширина, либо высота.

Что делать? Если окно вашего проекта имеет строго квадратную форму, то при любых пропорциях прямоугольника Rectangle печать содержимого, которое он ограничивает, будет пропорциональной. Отсюда первый вариант решения проблемы - делать окно проекта строго квадратным.

Второй вариант - это ресайзить окно проекта перед выводом на печать, используя команду SysCommand("ResizeWindow",""). Однако, как это ни странно, ресайзить нужно не до квадратных размеров, а до пропорций прямоугольника, лучше вообще до его размеров, при этом сам прямоугольник с его содержимым переносить в левый верхний угол проекта (с координатами 0,0). Тогда на печать выводится абсолютно правильно, независимо от пропорций прямоугольника, причем без всякого параметра fit выводится точно на страницу. Вот этот вариант и используйте.

Заметим кстати, что команда PrintPage() работает правильно всегда, при этом ширину окна проекта она приравнивает к ширине листа, независимо от высоты окна проекта. Так что предпочтительнее использовать именно команду PrintPage(), а не PrintRect().

Суть проблемы. Замечено, что если перед командой печати дать команду SysCommand("ResizeWindow",""), то приложение вылетает с ошибкой чтения памяти. Это одинаково как для команды PrintPage(), так и для команды PrintRect(). Причем срабатывает именно в скомпилированном приложении, тогда как при проверке по F5 всё работает нормально. Поэтому обнаруживается данный баг, к сожалению, только после компиляции.

Возможно, проблема существует и для других команд типа SysCommand, которые стоят непосредственно перед командой печати. Надо еще проверять.

ВНИМАНИЕ!!! Данный баг присутствует только в версии 497!

Что делать? Казалось бы, ответ прост: не давать дурацкую команду SysCommand("ResizeWindow","") перед выводом на печать. Однако именно эта команда рекомендуется для борьбы с багом номер пять. Вот ведь как...

Впрочем, и ту и другую проблему с печатью решить можно. Важно лишь знать об этих проблемах, а такое знание мы вам здесь уже дали:)