Головний (стартовий) файл проекту, FoxPro, Бази даних, статті

www.foxclub.ru

Кінцевою метою розробки програми є створення одного (або кількох) EXE-файла. Але це те, що повинне вийти у результаті. А на етапі його створення ми маємо велику купу найрізноманітніших файлів (Форми, запити, програмні модулі, класи тощо).

Виникає закономірне питання, який файл з цієї купи в готовому файлі EXE повинен запускатися першим? А як цей файл виділити (помітити, позначити)?

Ось цей самий файл, який в готовому файлі EXE повинен запускатися першим і називається головним (стартовим) файлом. Про нього і піде мова в даному розділі. Для простоти, далі я буду називати цей файл просто головним файлом.



Як виділити (помітити, позначити) головний файл

На етапі створення готового EXE-файлу всі наші файли включаються до загального файл проекту (файли з розширенням PJX і PJT). Файл проекту – це засіб якось упорядкувати ту купу файлів, з якої згодом буде зібраний готовий EXE-файл, а, крім того, це інструмент власне складання EXE-файла.

Так от, в FoxPro головний файл може бути позначений тільки і виключно всередині файлу-проекту. Не існує ніяких особливих ключових слів або синтаксичних конструкцій для його виділення в програмному коді.

За замовчуванням, перший доданий в проект файл автоматично ставати головним (якщо це можливо). Такий файл виділяється в проекті напівжирним шрифтом.

Якщо Вас не влаштовує такий автоматичний вибір, то Ви можете в будь-який момент вказати в якості головного файлу потрібний Вам файл. Для цього клацніть всередині проекту правою клавішею миші по потрібному файлу і в меню виберіть пункт “Set Main”. Обраний файл буде виділений напівжирним шрифтом, а файл, раніше позначений як головний файл, скине своє виділення і стане звичайним (не головним) файлом.

У межах одного файлу – проекту може бути тільки один головний файл

В принципі, допустимо взагалі не вказувати головний файл. Проте з такого проекту неможливо буде створити готового EXE-файла. На етапі компіляції виникне помилка з повідомленням про те, що Ви не вказали головний файл проекту.



Який тип файлу зробити головним

Головним файлом проекту може бути

Ну, по суті, файл меню – це і є програмний файл. Так історично склалося. Точніше, розробники FoxPro поки “не доросли” до корінної переробки ідеології побудови меню, як вони це зробили з формами, а в 9 версії і зі звітами.

Справа в тому, що хоча на етапі проектування меню – це файли з розширенням MNT, MNX, але після створення макета меню необхідно запустити його генерацію. Результатом генерації меню стають файли MPR, MPX. Ось ці-то файли і є звичайні файли PRG і FXP, тільки зі зміненим розширенням.

Отже, по суті, вибір стоїть між програмним файлом і файлом форми.

Так от, завжди вказуйте в якості головного файлу програмний файл. Більш того, це повинен бути саме файл PRG і ніщо інше.

Причин цьому безліч. У міру подальшого обговорення Ви побачите, що дуже багато з того, що треба зробити в головному файлі дуже важко, а іноді й просто неможливо реалізувати у формі.

В принципі, залежно від конкретного завдання, частину операцій в головному файлі, які будуть описані далі, можна і не виконувати. А що залишилися операції можна “втиснути” в форму. Але я не радив би цього робити. Програми мають “звичку” розростатися. А використання в якості головного файлу форми сильно звужує можливість модифікації.



Вміст головного файлу

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

Виходячи з так званого “здорового глузду” в головному файлі необхідно виконати всі ті операції, які виконуються при завантаженні програми. А також всі ті операції, які виконуються при вивантаженні програми, оскільки головний файл зазвичай буває і останнім (завершальним) файлом проекту. Тобто звичайно “вхід” у програму і “вихід” з неї – це один і той же файл.

Спробую просто перерахувати деякі дії, які слід виконати в головному файлі, якщо Ви пишіть “стандартне” додаток.

Це далеко не повний перелік усього того, що може (або повинна) бути виконано в головному файлі. Більше того, щось з перерахованого може або взагалі не виконуватися або виконуватися не в головному файлі.

У зв’язку з цим, надалі, я буду описувати не стільки те, що повинно бути власне в головному файлі, скільки те, що повинно бути виконане при старті програми. А вже де саме і яким способом Ви це реалізуєте у Вашому додатку цілком залежить від Вас. Для простоти, я буду припускати, що всі описані дії виконуються безпосередньо в головному файлі.



Ідеологія побудови програми

Як вже згадувалося раніше, вміст головного файлу проекту залежить в першу чергу від конкретного завдання. Наприклад, якщо метою Вашого проекту є створення COM-сервера, то в головному файлі взагалі нічого не буде.

Однак, в деякій мірі, вміст головного файлу залежить від прийнятої ідеології побудови програми. Тут, під фразою “ідеологія програми” я маю на увазі одну з таких реалізацій:

Побудова програми на базі основного вікна FoxPro припускає, що в кінцевому додатку користувач буде бачити це основне вікно (зрозуміло, зі своїм меню і ToolBar) і всі форми будуть відкриватися всередині цього основного вікна.

Побудова програми на базі “As Top-Level” форм припускає, що основне вікно FoxPro взагалі не буде відображатися в кінцевому додатку. А в якості основного вікна буде виступати створене програмістом вікно з властивістю ShowWindow = 2 – “As Top-Level form”

Розробники FoxPro припускали, що основною ідеологією побудови додатків буде побудова додатків на базі основного вікна FoxPro. На це вказує хоча б той факт, що значення за замовчуванням для властивості форми ShowWindow = 0 – In Screen (Default). Крім того, є ще ряд проблем, які виникнуть у міру реалізації програми на базі “As Top-Level” форм, пов’язані саме з відсутністю основного вікна FoxPro.

Як наслідок, побудова програми на базі “As Top-Level” форм вимагає підвищеної пильності від програміста і трохи складніше в реалізації. Не те, щоб ці складнощі були нездоланні або вимагали якогось складного програмування, але навіщо створювати собі зайві проблеми, коли без них можна обійтися?

Подальший опис вмісту головного файлу буде будуватися виходячи з припущення, що створюється додаток на базі основного вікна FoxPro. Втім, навіть якщо Ви будуєте додаток на базі “As Top-Level” форм вміст головного файлу залишиться практично таким же. Відмінності будуть в деяких деталях. У міру опису я буду вказувати на ці деталі.



Точка зупину. Read Events

При створенні програми основним керуючим елементом всього програми, як правило, є головне меню. Це означає, що в головній програмі необхідно зробити виклик цього меню

DO MainMenu.mpr

Синтаксично все абсолютно правильно. Більше того, коли Ви будете запускати головний файл, на етапі розробки програми все буде працювати нормально. Але ось після того, як Ви створите готовий EXE-файл і запустіть його, то замість очікуваного програми Ви побачите “дивний” ефект.

Вікно FoxPro промайне на екрані і тут же закриється.

Причиною такого “дивного” поведінки є те, що Ви “забули” вказати FoxPro, в якому місці йому треба зупинитися і почекати реакції користувача. На етапі налагодження такої “точкою зупинки” є раніше відкрите середовище FoxPro. Але в готовому файлі EXE до нього ніякої середовища FoxPro відкрито не було! Щоб створити “точку зупину” треба дати спеціальну команду

READ EVENTS

Тобто вміст головного файлу буде виглядати приблизно так:


DO MainMenu.mpr

READ EVENTS

Якщо Ви будуєте додаток на базі “As Top-Level” форм, то замість меню, основним керуючим елементом є Ваша головна форма. І вміст головного файлу буде виглядати приблизно так:


DO FORM MainForm.scx

READ EVENTS

Ось тепер, у готовому файлі EXE, коли програма дійде до команди READ EVENTS, то відбудеться зупинка в очікуванні реакції користувача.

Буквально, фраза “READ EVENTS” перекладається як “читання подій”. Тобто замість “точки зупину” це слід було б назвати якось на зразок “виявлення та виконання подій, ініціалізованих користувачем”. Це більш точно відображає суть і завдання даної команди. Але аж надто довго виходить. Тому, хоча “точка зупинки” – це не зовсім коректний термін, але надалі я буду використовувати саме його.

Майте на увазі, що одночасно, в усьому додатку може бути активна тільки одна команда READ EVENTS. Виклик іншої команди READ EVENTS не призведе до помилки, але ця команда буде просто проігноровано. Щоб скасувати дію команди READ EVENTS треба дати спеціальну команду

CLEAR EVENTS

За цією командою буде скасовано дію команди READ EVENTS і виконання перейде на команду, наступну за командою READ EVENTS. Якщо потім не буде подано ще однієї команди READ EVENTS, то головний файл буде виконаний до кінця і додаток автоматично закриється.

Якщо команда READ EVENTS була дана в головному файлі, то CLEAR EVENTS спрацює як команда RETURN TO MASTER. Тобто виконання тієї процедури або методу, де власне і була дана команда CLEAR EVENTS, буде перервана на цій команді і все що варто нижче цієї команди просто ніколи не буде виконано.

Так, де ж давати команду CLEAR EVENTS? Зрозуміло, у спеціальному пункті меню “Вихід”.

Якщо Ви створюєте додаток на базі “As Top-Level” форм, то команду CLEAR EVENTS треба давати в події UNLOAD Вашої головної форми.

Разом, виходить приблизно така логіка:



Аварійне припинення програми. Налаштування ON ShutDown

До цих пір, мова йшла про “штатному” завершення. Тобто коли користувач дисципліновано використовує всі належні пункти меню для виходу з програми. Але ж користувач може закрити програму, натиснувши на хрестик у правому верхньому кутку основного вікна FoxPro або, наприклад, через вікно “Диспетчер завдань Windows” (Ctrl + Shift + Esc).

Якщо все залишити так, як було описано до сих пір, то після такої спроби користувача вискочить повідомлення про помилку

Cann’t quit Visual FoxPro

Або, в старших версіях FoxPro без скорочень

Cannot quit Visual FoxPro

Причина такого повідомлення в тому, що залишилася активної команда READ EVENTS. Саме вона і викликає таке повідомлення про помилку в описаній ситуації. Щоб перехопити описані події закриття програми використовується спеціальна настройка

ON SHUTDOWN

В принципі, можна просто написати

ON SHUTDOWN CLEAR EVENTS

Але зазвичай перед закриттям програми треба виконати ряд попередніх операцій. Яких? Це вже залежить від Вашого застосування. Ну, наприклад, можна запитати користувача про те, чи дійсно він хоче вийти з програми або це в нього “рука здригнулася”. У загальному випадку однієї команди недостатньо. Потрібен виклик процедури. Наприклад:

ON SHUTDOWN DO MyExitProcedure

І ось вже в цій процедурі MyExitProcedure і треба дати команду CLEAR EVENTS. Причому ця команда повинна бути самою останньою, оскільки в момент її виконання управління буде передано на команду, наступну за командою READ EVENTS в головному файлі і все те, що написано після CLEAR EVENTS у процедурі MyExitProcedure просто не буде виконано.

Для універсальності, бажано в пункті меню “Вихід”, замість простої команди CLEAR EVENTS також зробити виклик цієї процедури. Тоді у Вас буде один загальний код, що обробляє вихід з Вашого застосування при будь-яких ситуаціях.

Оскільки вихід з програми може бути виконаний у будь-який момент і з будь-якого місця, то процедура MyExitProcedure повинна бути доступна також в будь-який момент і з будь-якого місця. Найпростіше розташувати це процедуру безпосередньо в головному файлі (в кінці). Оскільки головний файл – це “кореневої” файл, з якого здійснюється виклик будь-яких інших файлів, то розташована таким чином процедура буде “видно” і доступна з будь-якого місця Вашого застосування.

Якщо Ви робите додаток на базі “As Top-Level” форм, то виклик цієї процедури треба організувати ще й у події QueryUnload головної форми. Точніше так, у події QueryUnload головної форми треба перенаправити виклик на власне метод, організуючий закриття всього програми.

В результаті, вміст головного файлу набуває такого вигляду


ON SHUTDOWN DO MyExitProcedure

DO MainMenu.mpr

READ EVENTS



PROCEDURE MyExitProcedure

* Необхідні дії по “штатним” закриття програми

CLEAR EVENTS

RETURN



Чи треба давати команду QUIT для закриття програми

У FoxPro існує команда QUIT, яка призводить до негайного закриття програми FoxPro. Правда ця команда також перехоплюється налаштуванням ON SHUTDOWN і також по ній неможливо вийти з програми, якщо активна команда READ EVENTS.

Виникає резонне питання, а чи потрібна ця команда, якщо додаток FoxPro і так само закриється, коли завершиться виконання головного файлу?

Ну, особисто я вважаю, що це команда для лінивих програмістів. Тобто для тих, кому лінь відстежувати всі відкриті в додатку об’єкти. Як я вже згадував раніше, “штатний” закриття програми (вміст процедури MyExitProcedure) у загальному випадку – це дуже не тривіальна задача.

Ну, наприклад, користувач редагував будь-які дані у формі і натиснув на хрестик або пункт меню “Вихід”. Чи слід організувати “штатне” закриття форми або просто “зачинити” всі відкриті процеси?

По “правильному” логічно запитати користувача чи бажає він зберегти внесені зміни. Тобто організувати “штатне” закриття всіх відкритих об’єктів. А команда QUIT просто “розчавить” всі відкриті об’єкти без будь-яких додаткових питань і все!

Є й більш тонкі моменти. Тобто по хорошому, у процедурі MyExitProcedure треба організувати “штатне” закриття всіх відкритих об’єктів і після команди READ EVENTS (де власне і передбачається давати команду QUIT) взагалі не повинно залишитися нічого такого, що слід було б закривати саме командою QUIT. Якщо все-таки щось залишилося, то це явна недоробка розробника. І ця недоробка може дуже сильно “відгукнутися” в готовому додатку. Без команди QUIT Ви відловити цю проблему ще на стадії налагодження програми.

Крім того, використання команди QUIT може ускладнити налагодження. Що, кожен раз після запуску головного файла заново відкривати середу FoxPro? Втім, як це обійти, трохи нижче.

Разом, я не рекомендував би використовувати команду QUIT.



Як приховати головне вікно FoxPro (SCREEN)

У більшості випадків, незалежно від того в якій ідеології Ви розробляєте свій додаток при завантаженні середовища FoxPro бажано приховати головне вікно FoxPro (SCREEN). Якщо Ви розробляєте додаток в основному вікні FoxPro, то потім його можна буде переглянути. Ну, а якщо додаток на базі “As Top-Level” форм, то відображення його і не потрібно.

Можна першої ж командою в головному файлі дати команду

_SCREEN.Visible = .F.

Вікно FoxPro дійсно сховається. Однак перед цим встигне все-таки “майнути”. Не добре.

Щоб придушити відкриття головного вікна слід використовувати файл конфігурації Config.fpw. Це звичайний текстовий файл. У ньому повинна бути рядок:

SCREEN=OFF

Більш докладно про фото конфігурації розказано в інших розділах. Дана стаття присвячена тільки головному файлу.

Щоб знову відобразити головне вікно FoxPro (SCREEN) слід дати команду

_SCREEN.Visible = .T.

Якщо головне вікно FoxPro (SCREEN) і до цієї команди було відображено, то від цієї команди гірше не буде.



Як приховати системні ToolBar

Коли Ви запускаєте свій додаток в режимі налагодження, то системне меню замінюється Вашим меню. Але ось системний ToolBar залишається “висіти”, як ні в чому не бувало.

Строго кажучи, на системний ToolBar можна взагалі не звертати уваги. Справа в тому, що інформація про те, які саме системні ToolBar відкриті і де саме вони розташовані, зберігається в так званому “ресурсному файлі “. Типово, це файл FoxUser.dbf і пов’язаний з ним файл FoxUser.fpt.

Зрозуміло, Ви не потягнете користувачеві цей ресурсний файл. Як наслідок, на машині клієнта системні ToolBar взагалі не з’являться. Просто тому, що там не буде ресурсного файла з машини розробника.

Однак якщо на етапі налагодження Вам все-таки необхідно приховати системні ToolBar, то це можна зробити набором команд

HIDE WINDOW

Ім’я того чи іншого ToolBar можна подивитися в заголовку самого ToolBar (якщо він не “приклеєний” до меню) або через пункт меню View, підпункт ToolBars

Наприклад, приховати стандартну панель можна командою

HIDE WINDOW “Standard”

Знову активізувати стандартну панель можна командою

SHOW WINDOW “Standard”

Перевірити той факт, що та чи інша панель зараз активна можна використовуючи команду WEXIST ()


IF WEXIST(“Standard”) = .T.

      HIDE WINDOW “Standard”

ENDIF

Таким чином, якщо Вам дуже хочеться приховати системні ToolBar в режимі налагодження, то нескладно написати прості процедури їх закриття на початку головного файлу і відновлення після команди CLEAR EVENTS. Або ж використовувати клас, що поставляється з FoxPro.

MODIFY CLASS _systoolbars OF (Home()+”FFC\_app.vcx”)

Але, повторюся, особливого сенсу в готовому додатку це не має. Оскільки там їх і так не буде.



Налаштування середовища FoxPro

Раніше я побіжно вже згадав той факт, що просто запустити середу FoxPro недостатньо. Треба зробити деякі попередні налаштування. Хоча б настройку ON SHUTDOWN.

Справа в тому, що середовище FoxPro за замовчуванням налаштована таким чином, щоб полегшити створення нових і модифікацію старих програм. Тобто вона налаштована для зручності розробника. Але в готовому додатку така настройка середовища FoxPro не просто некоректне. Вона може виявитися неприпустимою!

Взагалі-то, налаштувань середовища FoxPro багато. Навіть дуже багато. Однак на практиці, для коректної роботи готового програми слід уточнити тільки декілька налаштувань. Найбільше – два … три десятки.

Частина налаштувань середовища FoxPro можна побачити через пункт меню Tools, підпункт Options. А щоб отримати ці налаштування в вигляді кодів натисніть і утримуйте клавішу “Shift” і лівою кнопкою миші натисніть на кнопку “Ok”. У командне вікно буде виведено всі поточні налаштування форми Options. У версії VFP9 список налаштувань буде виведений у вікно Output вікна Debugger.

Ви можете просто скопіювати отриманий список налаштувань і вкласти в головний файл. Зрозуміло, попередньо переглянувши, що саме з них дійсно потрібно для успішної роботи Вашого застосування.

Програмно можна отримати той же список поточних налаштувань середовища FoxPro, використовуючи команду DISPLAY STATUS

Складність у тому, що на етапі налагодження програми все-таки потрібні дещо інші настройки, ніж в готовому додатку.

Наприклад, на етапі налагодження добре б мати можливість перервати виконання якого-небудь процесу після натискання клавіші “Esc”, але в готовому додатку цього допускати в жодному разі не можна. Це регулює настройка SET ESCAPE.

Тобто виходить, що необхідно якось відрізняти, в якому режимі було запущено програму. В режимі налагодження або як готовий файл EXE.

Є кілька варіантів визначення режимів роботи. Найпростіший – це подивитися значення властивості

_VFP.StartMode

Якщо ця властивість має значення 0, то ми знаходимося в режимі налагодження. Тобто виходить щось на кшталт:


* Загальні настройки незалежно від режиму роботи

IF _VFP.StartMode = 0

* Установки тільки для режиму налагодження

ELSE

* Установки тільки для готового програми

ENDIF

Є й ще одна проблема налаштувань. Справа в тому, що при відкритті Private DataSession частина установок, пов’язаних з роботою з даними скидаються в значення за замовчуванням. Повний список таких настройок Ви можете подивитися в описі до команди “SET DataSession”. Причому для деяких налаштувань ці самі значення за замовчуванням відрізняються залежно від того, в якій DataSession ми перебуваємо.

Тобто виходить, що недостатньо просто один раз зробити налаштування в головному файлі. Потрібно ще повторити частина налаштувань в кожній Private DataSession.

Отже, виконання налаштувань середовища FoxPro треба винести або в окрему процедуру, або оформити як метод класу. Якщо як метод класу, то або як метод якоїсь базової форми, на основі якої будуть створені всі форми Вашого проекту, або як метод класу Custom, примірник якого буде “кидатися” на потрібні форми.

Нарешті, ще одна проблема налаштувань. По завершенні роботи програми треба повернути налаштування в той стан, в якому вони були на момент запуску програми.

На перший погляд, це здається абсолютно безглуздим вимогою. Але не треба забувати, що ми налагоджує наш додаток. Це означає, що є частина налаштувань, які просто зобов’язані відрізнятися в залежності від того, просто ми налагоджує якусь форму (процедуру) або запустили програму в режимі налагодження, починаючи з головного файлу.

Наприклад, при налагодженні тригерів добре б бачити записи помічені як видалені. Але в готовому додатку, навіть при запуску в режимі налагодження, нам бачити ці записи не треба. Це регулює налаштування SET DELETED

Та й в будь-якому випадку бажано завжди дотримуватися принципу: насмітив, прибери за собою. Для програмування це особливо важливо у всіх сенсах.

Таким чином, у загальному випадку, робота з налаштуваннями виглядає приблизно так:

З цієї логіки випливає, що використовувати процедури в принципі можна, але дуже вже незручно. Потрібні дві окремі процедури для установки і для відновлення налаштувань. А, крім того, потрібно десь зберігати старі налаштування.

Більш зручним здається використання класів. Створюються два методи одного і того ж класу (можливо більше, адже для Private DataSession треба встановити тільки частина налаштувань). А для зберігання старих значень налаштувань можна використовувати властивості (Properties) класу.

Тоді залишається уточнити, чи використовувати клас Custom або клас на базі Form?

За великим рахунком – це абсолютно однакові варіанти. Слід лише пам’ятати, що методи класу Custom можна запустити не раніше події Init цього класу. Але в будь-якому випадку методи власне форми або будь-яких її об’єктів ще не існують на момент виконання події BeforOpenTables в DataEnvironment форми. Тобто автоматичне відкриття таблиць, включених до DataEnvironment форми, станеться з використанням параметрів за замовчуванням.

Але в більшості випадків, це не настільки вже й принципово. Чому? Це окреме питання, що виходить за рамки цієї статті. Просто візьміть до відома, що виконання налаштувань в INIT-форми в більшості випадків цілком доречно і не буде “занадто пізно”.

Повертаючись до вмісту нашого головного файлу, отримуємо, що його вміст уже виглядає приблизно так:


* Підключаю бібліотеку класів, містить ряд корисних класів загального призначення

LOCAL loSetting, llIsClass

IF UPPER(“MyClass.VCX ALIAS MyClass”) $ UPPER(SET(“ClassLib”))

      llIsClass = .T.

ELSE

      llIsClass = .F.

      SET CLASSLIB TO MyClass ADDITIVE

ENDIF



* Клас, який встановлює глобальні налаштування середовища (знаходиться в MyClass.VCX)

loSetting = CREATEOBJECT(“Setting”)



ON SHUTDOWN DO MyExitProcedure

PUSH MENU _MSYSMENU

DO MainMenu.mpr

_SCREEN.Visible = .T.

READ EVENTS



********* Відновлення початкових налаштувань

POP MENU _MSYSMENU

ON SHUTDOWN

IF m.llIsClass=.F.

      RELEASE CLASSLIB MyClass

ENDIF



******** Процедура “аварійного” виходу з програми

PROCEDURE MyExitProcedure

* Необхідні дії по “штатним” закриття програми

CLEAR EVENTS

RETURN

Тут я припускаю, що в бібліотеці класів MyClass.VCX є клас “Setting” у події Init, якого відбувається встановлення потрібних налаштувань, а в події Destroy відновлення вихідних налаштувань. Тобто видалення змінної m.loSetting означає автоматичне відновлення вихідних налаштувань.

Ще використані додаткові команди PUSH MENU і POP MENU, які зберігають і відновлюють системне меню FoxPro.

Зверніть увагу на те, що змінні оголошуються як LOCAL. Справа в тому, що якщо не оголосити змінні, то за умовчанням вони отримають область видимості PRIVATE. А для змінних головного файлу це рівнозначно оголошенню їх як PUBLIC, оскільки вони будуть видні в усіх викликаних формах і процедурах.

Ще один тонкий момент полягає в тому, що команди, записані після команди READ EVENTS, будуть виконані тільки після подачі команди CLEAR EVENTS. Тобто все те, що позначено, як “Відновлення початкових налаштувань “буде виконано безпосередньо перед закриттям програми.

Як бачите, головний файл починає розростатися. З цим треба щось робити. Чим більше лістинг програми (код одного методу чи процедури), тим складніше такий код налагоджувати і модифіковані.



Використання глобального об’єкта goAPP

До цих пір, я описав лише частина того, що в принципі мало б бути в головному файлі. Фактично, описаний самий мінімум, без якого складно написати повноцінне додаток. В принципі, можна залишити все “Як є”. Якщо проект не дуже великий і не передбачається його активний розвиток, то того, що вже описано цілком вистачить.

Однак у міру розвитку проекту одного файлу PRG для управління завантаженням і розвантаженням проекту виявляється недостатньо. “Недостатньо” не в сенсі “мало”, а в сенсі “не зручно”

Справа в тому, що у великому проекті необхідний цілий набір різних процедур і функцій, які повинні запускатися як при старті програми, так і при його завершенні. Ось деякі з них:

Це, ще не рахуючи ряду специфічних процедур, які необхідно запустити при старті в конкретному проекті залежно від конкретного завдання. Та ще додайте до цього все те, що вже було описано раніше.

Зрозуміло, все це можна реалізувати в ідеології процедурного програмування. Тобто написавши потрібну кількість процедур і розкидавши їх по процедурних файлів. Або створити один великий процедурний файл. Але у такого підходу є ряд недоліків. Наприклад:

Ось для вирішення цих проблем і ще багатьох інших створюється спеціальний клас на базі класу Custom. Примірник цього класу зазвичай і називають goApp.

Приклад реалізації такого класу можна подивитися в стандартному проекті, що поставляється разом з FoxPro під назвою TasTrade.pjx

MODIFY PROJECT (HOME(2)+”tastrade\tastrade.pjx”)

По суті, якщо опустити деякі деталі, вміст головного файлу в цьому випадку буде виглядати приблизно так:


SET CLASSLIB TO MAIN, TSGEN

PUBLIC goApp

goApp = CREATEOBJECT(“TasTrade”)

goApp.Do()

У чому тут “фокус”? А “фокус” в тому, що в момент створення об’єкту на базі класу TasTrade виконується його подія Init. А вже з події Init цього класу здійснюється виклик всіх тих методів, які необхідні в цьому додатку в момент завантаження програми

Метод goApp.Do () містить власне команду READ EVENTS, що і забезпечує “точку зупину” всього програми.

Команда CLEAR EVENTS дається в одному з методів класу goApp. У даному випадку – це метод goApp.CleanUp2 ()

Методи, які необхідно виконати при закритті програми можна викликати в тому ж методі goApp.Do () після команди READ EVENTS або в події goApp.Destroy ()

Всі ті процедури, які були описані в цій статті, оформляються як окремі методи класу TasTrade. І викликаються у відповідному місці класу.

Зверніть увагу, що власне клас TasTrade з бібліотеки класів Main.vcx є спадкоємцем іншого класу Application з бібліотеки класів TSGen.vcx. Така “ієрархія” зовсім не випадкова. У цьому випадку Ви можете використовувати клас Application у всіх Ваших програмах, створюючи на його основі власний клас, наприклад, MyClass у власній бібліотеці класів MyClass.vcx. Тобто Ви отримаєте якусь загальну бібліотеку класів взагалі для всіх ваших проектів, як заготовку для класу конкретного додатка.

Кілька слів про те, чого не повинно бути в класі goApp.

Справа в тому, що виникає велика спокуса “впихнути” в клас goApp взагалі всі глобальні методи, змінні пам’яті і різні обробники. Так от, не треба цього робити.

Мета класу goApp – це організувати коректну завантаження і вивантаження вашого застосування. Все! Все що “понад” цього завдання має бути виділено в окремі класи. Наприклад:

Список можна продовжувати. Але основний принцип: не змішувати в одному об’єкті різні завдання.

Будьте обережні з використанням класу з проекту TasTrade.pjx. Він досить далекий від ідеалу. Його слід розглядати швидше як навчальний посібник, але не як об’єкт готовий до використання. Не треба сліпо копіювати його в своє застосування. Краще напишіть свій власний клас. Так, це займе більше часу, але Ви краще зрозумієте що це таке і для чого це використовується.



Передача параметрів в EXE

Як правило, готовий файл EXE самодостатній у тому сенсі, що йому не потрібно передавати будь-які параметри. Всі необхідні “зовнішні” настоянки робляться або у файлі CONFIG.FPW, або в спеціальних ini-файлах. Але іноді така необхідність все-таки виникає. Наприклад, щоб вказати, де саме знаходиться потрібний ini-файл.

В системі Windows загальноприйнятим стандартом є вказівка ​​параметрів відразу за ім’ям програми через пробіл:

MyProg.exe Par1 Par2

Для прийому таких “зовнішніх” параметрів у головному файлі в якості першої виконуваної команди треба дати стандартну команду PARAMETRS (або LPARAMETERS)

PARAMETERS tcPar1, tcPar2

Тобто з точки зору коду FoxPro нічого нового і незвичайного. Стандартний список параметрів через кому як перша виконувана команда програмного модуля.

Однак є деякі відмінності в прийомі “зовнішніх” параметрів

По-перше, Один параметр від іншого розділяється прогалиною, тому якщо Ви хочете передати в свій додаток якусь символьну рядок, яка сама містить прогалини, то її слід взяти в лапки

MyProg.exe “перший параметр” “другий варіант”

По-друге, Всі зовнішні параметри, передані у додаток FoxPro, мають символьний тип даних. Тобто навіть якщо Ви дасте команду:

MyProg.exe 1 2

То в програмі FoxPro будуть прийняті не числа 1 і 2, а символи “1” і “2”

По-третє, Незважаючи на те, що здається, ніби в момент запуску Вашого застосування відразу воно і починає виконуватися, але насправді це не зовсім так. Спочатку відбувається завантаження середовища FoxPro і тільки після цього вже з завантаженою середовища FoxPro починає виконуватися Ваша програма.

Стосовно передачі параметрів у Ваше додаток з цього випливає, що спочатку передані параметри будуть прийняті і оброблені власне середовищем FoxPro. Але вся справа в тому, що саме середовище FoxPro в момент завантаження може приймати кілька іменованих параметрів (Перемикачів, ключів).

Іменовані параметри середовища FoxPro починаються або з символу дефіса (знак мінус), або з похилої риси (знак ділення). Повний список іменованих параметрів і для чого вони призначені, Ви можете подивитися в HELP до Visual FoxPro в розділі з ім’ям кшталт “Command-line switches in Visual FoxPro

Як саме називається цей розділ, і в якій саме статті він знаходиться, залежить від версії FoxPro. У різних версіях він знаходиться в різних статтях. Тому відкрийте HELP до Вашої версії FoxPro, перейдіть на закладку “Пошук” і введіть ключове слово “switches” для пошуку. Найперша з знайдених статей, швидше за все і буде містити список і опис “ключів”.

Починаючи з версії Visual FoxPro 7.0 список ключів можна отримати, запустивши середу FoxPro з ключем “/?”. Приблизно так:

“C:\Program Files\Microsoft Visual FoxPro 8\vfp8.exe” /?

Тут я не буду описувати ці самі “ключі” і для чого вони призначені. Для нас більш важливим є те, як використання ключів FoxPro вплине на передачу параметрів в створене додаток.

Виявляється, ці самі “ключі” перехоплюються самої середовищем FoxPro в момент її запуску та виключаються зі списку переданих параметрів. Наприклад, якщо Ви дасте команду:

MyProg.exe -t 1 2

То в момент завантаження середовища FoxPro буде знайдений ключ “-t”. Цей ключ буде відповідним чином оброблений середовищем FoxPro, а безпосередньо виклик Вашого застосування набуде вигляду:

MyProg.exe 1 2

Таким чином, “ключі” FoxPro просто виключаються із списку параметрів, переданих у Ваше додаток. Тому будьте акуратніше у виборі значень зовнішніх параметрів Вашого застосування.



Висновок

У даній статті були розглянуті основні ідеї по вмісту головного файлу проекту FoxPro. Причому, не взагалі все, що тільки можна і не можна “впихнути” в головний файл, а тільки самий мінімум. Без чого проблематично написати повноцінне додаток.

У статті свідомо не давалося докладний опис коду тієї чи іншої частини головного файлу. Знову ж таки, тільки самий мінімум, як загальна ідея того, що має бути.

Є кілька причин, такого “поверхневого” опису:

Тобто просто не існує якогось “стандартного” коду для головного файлу проекту. Є тільки деякі стандартні завдання, Які слід вирішити в головному файлі. Ось саме ці завдання і найбільш прості шляхи їх реалізації і були описані в цій статті.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*