Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
NNN
Member

Откуда:
Сообщений: 2141
2Ermak

> Хотелось бы узнать о VFP, как средстве разработки клиента несколько поподробнее, в частности:
- Какие инерфейсы доступа к данным поддерживает VFP?


Собственные функции у фокса есть только для ODBC. В 8-й версии была расширена поддержка ADO (ее можно было использовать и раньше через CreateObject(), но CursorAdapter намного облегчает работу с ADO, о чем Crip уже писал). Но! Есть возможность создания библиотек на C/C++, поэтому можно говорить о возможности использования практически любого интерфейса.
Из того, что я видел или слышал краем уха:
  • Существует библиотека для работу напрямую с OLEDB, дублирующая родные функции ODBC и расширяющая некоторые возможности.
  • Существует библиотека, использующая для работы DB Library SQL Server (жаль развитие DB Library остатновлено, мне говорили, что эта связка работает очень быстро).
  • Существует библиотека, использующая для работы Native API Oracle.
    Наверное есть и другие.Если вас не устраивают сторонние библиотеки, то у вас всегда есть возможность написать свою собственную. Это, конечно, потребует намного больше времени, чем при работе с RAD, но, во-первых, эти модули будут использоваться повторно, а во-вторых иногда результаты превосходят ожидания.
    Из личного опыта: более-менее серьезно писал библиотеки только для Novell, но вы бы видели выражения лиц бывалых админов, когда я им демонстрировал возможности, которые предоставляет NDK, но нет в стандартных средствах.
    Кроме того, используя COM, можно обращаться не только к ADO, но и к компонентам .NET, включая соответственно ADO.NET. Даже видел в инете по этому поводу обширную статью.
    И еще, несмотря на то, что родных функций для ODBC около десятка, вы можете использовать любую внутреннюю функцию ODBC, для этого, как правильно не нужно даже использовать С+FoxAPI, достаточно объявить функцию:
    declare [..] FuncName in odbc32.dll ..

    > - Если можно, то с Вашей личной оценкой, что хорошо, а что плохо реализовано?

    Все вроде бы реализовано довольно неплохо. Говорят, что бывает лучше, но то, на что меня пихали не произвело на меня особого впечатления. Если подойти серьезно и хорошо во всем разобраться думаю никаких проблем не будет. Главное не забывать, что кроме foxhelp.chm в msdn есть и другие файлы :)
    Лично меня больше беспокоит отсутствие нормальной многопоточности и устаревший генератор отчетов, да и встроеное средство для отображения диаграм не помешало бы. А несбыточная мечта - прямой доступ из VFP к SQL Server по TDS-протоколу :)
    В целом, в фоксе, конечно, есть шероховатости, которые иногда мешают, но особых проблем никогда не было.

    > - Доступ к каким SQL серверам будет эффективен при разработе клиента на VFP (будет здорово, если будут ссылки на собственный опыт)?

    Исходя из первого пункта - имя сервера особого значения не имеет :)
    Собственный серьезный опыт с клиент-сервером довольно небольшой, всего два года, но связка VFP+SQL Server меня вполне устраивает. Опыты с Oracle тоже вполне успешно проводились с использованием фокса, но так получилось, что это было совсем недолго.
    Кроме того, написать клиентское приложение на фоксе, которое бы не зависило от типа сервера (конечно, используя какие-либо механизмы настройки для оптимизации) - вполне разрешимая задача.

    > -У меня после чтения тутошних форумов сложилось ощущение (заметьте не мнение, а именно ощущение), что связка VFP + MS SQL2000 будет работать лучше, беспроблемнее, чем допустим VFP + SQL производства не Microsoft. Если это так, то почему, за счет каких механизмов, если не так, то почему такое мнение существует?

    ИМХО такое мнение существует прежде всего потому, что серверная БД поставляется либо с собственным средством разработки (в котором к тому же могут быть использованы недокументированные возможности и т.д.), либо все клиентские примеры в документации приводятся на определенном языке программирования. Ясное дело, никто не хочет лишний раз рекламировать продукт конкурента. Из объективных причин могу принять лишь отсутствие ODBC-драйвера и то с оговорками. Поэтому здесь больше вопросы маркетинга, политики и проч. А о том, что лучше всего писать программы лучше всего на том, что хорошо знаешь, я уже говорил :)
  • 20 июл 03, 13:52    [268589]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Ermak
    Member

    Откуда: Tomsk
    Сообщений: 811
    2NNN (Crip не оставайся в стороне)
    "Собственные функции у фокса есть только для ODBC"...

    ODBC так ODBC.

    "И еще, несмотря на то, что родных функций для ODBC около десятка, вы можете использовать любую внутреннюю функцию ODBC, для этого, как правильно не нужно даже использовать С+FoxAPI, достаточно объявить функцию:
    declare [..] FuncName in odbc32.dll .. "

    Возможность использования ф-ий WinAPI32 это хорошо.
    В PB это тоже имеет место быть.
    Несмотря на то, что как правило в PB, соединение с БД происходит через ODBC не пришлось обращаться к внутренним ф-циям API ODBC.

    Давайте пройдемся по ODBC сначала до конца. Допустим мы решили подключиться к какой-нибудь БД, используя для этого ODBC. Для этого, я например, буду спользовать примерно такой код

    SQLCA.DBMS = "ODBC"
    
    SQLCA.DBParm = "ConnectString='DSN=DB_1C;UID=;PWD='"


    Понимаю, что это глупо (прямо извращение какое-то) из VFP подключаться к ИБ 1С через какое-то там ODBC, но всетаки как это будет выглядеть на VFP?
    Просто я думаю, что комплект ODBC драйверов от Microsoft у Вас на ПК скорее всего уже установлен (Microsoft Visual FoxPro Driver).

    Строка 1 говорит, что в качестве интерфейса доступа к данным будем использовать ODBC, строка 2 говорит, что подключаться будем к DSN = DB_1C.
    Так как ИБ 1С состоит просто из набора *.DBF файлов, то для подключения к БД не требуется задавать имя подключеня (UID) и пароль (PWD).

    PS. В принципе можем пройтись не через *.DBF базу, а допустим через какой-нибудь SQL сервер (Использую ASA, могу установить ещё MS SQL 7., на Free BSD крутится PostGre SQL. Других дистрибутивов у меня просто нет.).
    20 июл 03, 17:51    [268693]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    NNN
    Member

    Откуда:
    Сообщений: 2141
    2Ermak

    > Несмотря на то, что как правило в PB, соединение с БД происходит через ODBC не пришлось обращаться к внутренним ф-циям API ODBC.

    Для 99% процентов случаев достаточно того, что предоставляют собственные функции фокса. Но иногда хочется выйти за эти пределы, например, получить всю информацию, предоставляемую SQLGetInfo, что можно сделать только с помощью обращения к API.

    > Понимаю, что это глупо (прямо извращение какое-то) из VFP подключаться к ИБ 1С через какое-то там ODBC, но всетаки как это будет выглядеть на VFP?

    Синтаксис будет очень похож. Если используется DSN, то лучше так:
    hConn=sqlconnect('DB_1C','','')

    Но можно и указать строку подключения без DSN. Примерно так я подключаюсь к тестовой базе на работе:
    hConn=SQLSTRINGCONNECT('driver=sql server;server=testserver;database=mydb;uid=sa;pwd=')

    Можно вообще ничего не указывать, в этом случае откроется окно выбра DSN и всю информацию можно будет ввести и выбрать интерактивно.
    Надеюсь все понятно и ничего объяснять ненужно:)
    Кроме того, можно создать объект Connection, который будет храниться в фоксовской БД, и использовать совместно с REMOTE VIEW. Там аналогично указывается DSN, логин и пароль, либо строка подключения. В этом случае подключение подключение будет установлено при обращении к REMOTE VIEW, естественно возможно совместное использование одного подключения несколькими вьюхами. Но REMOTE VIEW - это ближе к рекордсету, а до него мы еще не дошли :)
    20 июл 03, 18:37    [268716]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    funikovyuri
    Member

    Откуда: Симферополь
    Сообщений: 4045
    Остается только требовать новый порум по PB!
    Кто за збор подписей?
    21 июл 03, 11:20    [269150]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    funikovyuri
    С одной стороны было бы неплохо, очень удобные форумы на sql.ru . Проблема в том, что не так уж много разработчиков на PB в России. Если поглядеть на форумы по PB Sybase Developer или же Sybase.ru, то активность форумов почти нулевая. В основном как то больше получается по почте или Аське общаться с коллегами, работающими с PB. Хотя кто знает - может быть на sql.ru при соотвествующей агитации народ и пошел бы в форум :)

    NNN
    Насчет отношения к VFP, как старому foxpro, Вы абсолютно правы - многие так и делают. Именно поэтому я и подчеркнул, что с VFP не работал. Однако когда я описывал PB, я постарался обьяснить, что с моей точки зрения по концепциям работы он стоит в стороне от распостраненных ООП языков программирования, таких как Delphi, C#, Java, с фоксом я сравнений старался не проводить. Несмотря на то, что они поддерживают все, что может PB и даже намного больше, будучи универсальными мощными средствами построения любых GUI-клиентов, с моей точки зрения "цельность" функциональности PB и его узкоспециализированность выигрывает по сравнению с универсальностью компонентно-ориентированных средств. Например DataWindow как средство ввода и просмотра данных по возможностям ничем не уступает мощным гридам сторонних производителей для других языков программирования (тот же QuantumGrid или UltraGrid), одновременно как средство построения отчетов и графиков он не остает от Crystal Report, плюс как компонент "набор-данных" он позволяет легко обрабатывать и манипулировать данными, поддерживая все современные концепции доступа к данным (те же отложенные/кэшированные изменения). Включаем сюда еще язык выражений, который поддерживается DataWindow и получаем, что только один DataWindow по возможностям и функционалу предоставляет то, что в других языках было бы реализовано с использованием кучи компонент, причем в основном сторонних производителей. Следует еще подчеркнуть, что спроектированный DataWindow нельзя назвать компонентом - хранится он как описание получения данных, правил их изменения и верификации и визуального отображения. Такое представление является автономным - его можно создавать динамически или же подгружать с любого источника (файловой системы, BLOB-ов и т.д.) и в любой момент запустить в приложении, указав его в кач-ве источника для визуального контролса DataWindow, лежащего на какой-то форме. Так же есть возможность использовать DataWindow без его визуализации в невизуальном классе DataStore.

    Думаю понятно что я хотел этим сказать - главное преимущество PB - это его высокоуровневость и специализированность на уровне языка и встроенных средств работы с данными. Я считаю, что в свое время fox в файл-серверных системах и получил широкое распостранение и известность именно благодаря тем же вышеописанным качествам, имея специальный встроенный dbase язык манипуляции данных и неплохие средства их визуального отображения на уровне самой системы (думаю все со мной согласятся). Поэтому и хотелось бы узнать от специалистов, работающих на VFP и знающих динамику его развития - что представляет из себя сейчас VFP - к кому он теперь ближе - к компонентным ООП языкам или же он остался таким же специализированным языком, но уже с продвинутыми возможностями построения клиент-серверных приложений ? Поддерживает ли он изначально все то, что есть во многих других средствах, не только в PB - мощные гриды, построение сложных отчетов, кросстабов, графиков, сохранение в БД посредством отложенных изменений, фильтрацию и сортировку наборов данных, работу с множествами записей, возможность организации форм ввода и просмотра данных и отчетов для интернет-браузеров и построение 3-звенных систем ? И самое главное - если может, то насколько это реализовано "аппаратно" в самом фоксе - сколько кода и усилий необходимо приложить для реализации вышеперечисленных возможностей.

    P.S. В Delphi или .NET например из этого можно все, но только с учетом использования сторонних компонент и то во многих случаях приходится все равно писать немало дополнительного кода. В PB так же из этого можно все, но почти без написания дополнительного кода и вообще без каких то дополнительных компонент.
    21 июл 03, 13:28    [269457]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Crip
    Member

    Откуда:
    Сообщений: 2490
    Поэтому и хотелось бы узнать от специалистов, работающих на VFP и знающих динамику его развития - что представляет из себя сейчас VFP - к кому он теперь ближе - к компонентным ООП языкам или же он остался таким же специализированным языком, но уже с продвинутыми возможностями построения клиент-серверных приложений ?
    Нечто среднее. Это и специализированный язык, но в тоже время с развитыми средствами ООП. Подробно расписывать неохота, проще ответить на вопросы, тем более, что о языковых возможностях фокса я вроде не раз писал.

    Поддерживает ли он изначально все то, что есть во многих других средствах, не только в PB - мощные гриды, построение сложных отчетов, кросстабов, графиков,
    Согласно современным требованиям думаю нет. Для этого В основном используются сторонние продукты. Именно поэтому я ранее автору поста рекомендовал все же PB.

    сохранение в БД посредством отложенных изменений, фильтрацию и сортировку наборов данных, работу с множествами записей,
    Да...

    возможность организации форм ввода и просмотра данных и отчетов для интернет-браузеров и построение 3-звенных систем ?
    И самое главное - если может, то насколько это реализовано "аппаратно" в самом фоксе - сколько кода и усилий необходимо приложить для реализации вышеперечисленных возможностей.

    Да, но в плане интернета есть ограничения. Тут фокс рассматривается MS как возможность построения приложений среднего звена и Web Services.
    21 июл 03, 13:47    [269512]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    NNN
    Member

    Откуда:
    Сообщений: 2141
    2ASCRUS

    Поскольку Crip вернулся и ответил на всё, то позвольте мне задать несколько вопросов.

    1. Про DataWindow - насколько его универсальность избыточна и как это влияет на производительность?
    2. Про Grid - что подразумевается под гридом, отвечающим современным требованиям.

    2Crip

    А что ты такого не смог сотворить в фоксовском гриде? Просто интересно, что люди с гридами творят.
    21 июл 03, 14:23    [269611]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Alex Antipenko
    Member

    Откуда: Ukraine, Lviv
    Сообщений: 110
    И ещё один вопрос:

    Какие объём библиотек поддержки для PB?

    спасибо.
    21 июл 03, 15:51    [269826]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    Crip
    Сенкс за ответ. Будет время, ради интереса надо будет поюзать VFP в просветительских целях :)

    NNN
    В принципе как не странно, такая вот универсальность DataWindow не ущемляет разработчиков в решении каких то специализированных решений и ничуть не снижает скорости обработки данных. Сам DataWindow по заверению разработчиков изначально проектировался, как средство обработки больших обьемов данных, не даром у него есть опции различных вариантов получения и хранения наборов данных - весь в памяти, считывание с сервера по мере необходимости и хранение посредством кэша на диске. Я единственное не понимаю, как они умудрились создать внутренний интерпретатор выражений под DataWindow, который может использовать не только собственные внутренние функции, но и внешние, написанные на языке PB - PowerScript, при этом довольно таки шустро работая.

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

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

    Для конвертации и больших перегонок данных между различными источниками данных есть DataPipline, смахивающий по принципам на DTS из MSSQL.

    Насчет гридов - очень легко можно организовывать гриды с группировками, аггрегирующими и вычисляемыми столбцами, "expression" позволяют на любое свойство описать выражение, возвращающее его значение в зависимости от заданных условий, на DataWindow сразу можно расписать правила целостности полей, легко организуются навороченные lookup поля посредством подключения в виде выпадающего списка любого указанного DataWindow. Естественно любой DataWindow может себя отпечатать в виде отчета, причем в настройках DataWindow изначально можно указать, что будет присутствовать в отчете, а что только показываться на экране. Метод кэширования DataWIndow позволяет организовывать на один набор данных множество DataWindow с различными видами представлений информации, служащих как для ввода данных, так и для предоставления отчетов и графиков, как я уже и говорил раньше имея каждый в отдельности собственную текущую позицию записи в наборе данных.

    Также в PB имеется полный набор функций управления печатью - распечатать можно все что угодно, плюс можно организовывать очереди печати и печатать туда формы, DataWindow и вручную управлять выводом на листы текстов, графики и т.д.
    21 июл 03, 16:18    [269881]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    Alex Antipenko
    Привожу данные под Windows версию:
    если брать полную версию ядра PB - то 8 мегабайт. Плюс dll-ки для доступа к нужным интерфейсам доступа к данных - например для доступа через ODBC dll весит 500 кило. Если реализуется поддержка 3-звенки или web-а, то в инсталяцию включаются дополнительные dll, отвечающие за соотвествующие функции.

    Под другие ОС насчет размеров не знаю, наверное примерно те же самые обьемы.
    21 июл 03, 16:32    [269921]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Crip
    Member

    Откуда:
    Сообщений: 2490
    2NNN
    Ну скажем так...Вы Quantum Grid наверное видели. Фоксовому гриду до него далеко. Печать данных нужно реализовывать самому. Хотя это не столь тяжелое занятие. Я уже не говорю про всякие навороты реализованные через SHAPE.
    фоксовый грид даже до DbGridEh ИМХО не дотягивает. Вообще чтобы было также круто надо юзать внешние компоненты.
    Еще раз повторюсь. Пока отчетность в фоксе сделана так себе...В девятке обещают вроде несколько поправить сей недостаток
    21 июл 03, 16:53    [269959]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    NNN
    Member

    Откуда:
    Сообщений: 2141
    2ASCRUS

    Спасибо за подробный ответ. При возможности также попытаюсь потрогать руками. Или хотя бы что-то позаимствовать, в моей библиотеке есть пара узкоспециализированных классов, которые отдаленно напоминают DataWindow.
    Ну а что, насчет недостатков, чего не хватает?
    (извиняюсь, если чего пропустил)

    2Crip

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

    > В девятке обещают вроде несколько поправить сей недостаток

    Ну годик подождать - не проблема :)
    21 июл 03, 16:56    [269971]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    В принципе стандартных возможностей PB хватает для нормальной жизни. Не хватает полноценного экспорта в excel, экспортироваться в него могут только данные с DataWindow, а не отчет. Есть конечно нормальный экспорт в HTML, PDB и WMF, но это не то, что частенько нужно. Судить больше о том что не хватает сложно - я на самом деле не могу считать себя спецом в PB с учетом того, что недавно с ним познакомился и использую пока больше как генератор отчетов для своего проекта. Фактически я пользуюсь только стандартными наворотами самого PB, а на самом деле еще мегов на 12 у него в комплекте идет огромная библиотека иеархий готовых решений классов, форм и компонент PFC (Power Builder Foundation Class Library). Там чего только нет, по моему на все случаи жизни - достаточно брать уже готовые каркасы, наследоваться и дописывать частные решения. Я пока с PFC не работал, хотелось поюзать сам PB, понять его принципы и методики работы. Хотя если начну крупный проект писать на PB, то PFC буду использовать обязательно, так как мне уже очевидно, что многие сложные решения, которые я сейчас в своем маленьком приложении пишу ручками на "чистом" PB, в PFC уже достаточно полно предоставлены множеством удобных решений.

    В качесте явных недостатков можно назвать некоторую глюкавость самой IDE PB и способы компиляции исходных текстов программ. Например автокомпиляция кода функции или события приводит к тому, что я не могу в них сослаться на несуществующую функцию или переменную и потом перейти в раздел, где я ее и опишу. Лечиться только ремарками - заремарили, описали новую функцию, вернулись, разремарили. То же самое можно сказать и про ООП - если у базового класса удалить свойство или метод, который вызывается из наследуемых классов, то их дизайнер открыть не удасться - придется вызывать редактор исходника такого класса и ручками убрать ссылки на несуществующие более свойства или методы. Далее я так понимаю в PB при изменении иеархии классов или их аттрибутов их наследники не перекомпилируются и остаются со старым байт-кодом, лечиться полной или частичной перекомпиляцией проекта (под словом компиляция я понимаю не компиляцию в машинный код, как например в Delphi, а компиляцию в байт-код, как у VB, то есть процесс этот не занимает много времени). В принципе кое-что я обьяснить для себя в таких вот недостатках PB могу - динамическое подключение и связывание библиотек во время выполнения это не шутки и многие ограничения насколько я понимаю идут оттуда. В принципе я на них сильно не жалуюсь, так как полностью поддерживаю взгляды разработчиков PB, что проектировать надо сразу и не есть хорошо базовую иеархию классов в середине пути изменять, но вот навязывать такие пусть и хорошие правила программирования все таки жестоко. Ну и немного непривычный и во всяком случае для меня неудобный отладчик, который иногда просто неизвестно почему при пошаговом выполнении кода может снести как процесс сам PB. Также не понятна ситуация с машинным кодом - вроде бы PB полностью поддерживает 2 модели работы приложений - через байт-код и прямые откомпиленные exe-файлы с dll, однако я слышал, что нативные файлы могут глючить и не все правильно выполнять, но об этом уже более знающих людей надо спрашивать, чем я.

    Ну а в самом выполнении функциональности программ пока глюков я не нашел, хотя сейчас юзаю PB пожесткому, чтобы определить его слабые и сильные стороны и точно знать, что точно в нем делать не стоит.
    21 июл 03, 17:47    [270070]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    NNN
    Member

    Откуда:
    Сообщений: 2141
    2ASCRUS

    Еще раз спасибо.

    Больше вопросов вопросов не имею, поэтому покидаю этот топик. Хотя если будут вопросы по VFP, появится что-то интересное или Crip'у понадобиться помощь и у меня будет свободная минутка, то непременно вернусь (при условии, что Crip перестанет на меня выкать).
    21 июл 03, 22:19    [270280]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Crip
    Member

    Откуда:
    Сообщений: 2490
    при условии, что Crip перестанет на меня выкать
    LOL... Договорились
    22 июл 03, 10:33    [270510]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    sergei_p
    Member

    Откуда: Краснодар
    Сообщений: 518
    Как в PB установить у элементов управления привязку к краю окна? Есть ли такая возможность вообще?
    22 июл 03, 11:26    [270618]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    В самом PB такого нет и судя по 9 версии не предвидится. Существует 2 пути:
    1. прописать все ручками на событие resize контейнера компонента
    2. воспользоваться pfc, в которой есть специальная функция размещения компонент по форме. Функция довольно таки мощная и позволяет расписать не только выравнивание компонент по форме, но и их пропорциональность в размерах и даже zoom в DataWindow. По принципам работы и функциональности один в один, как схема GridBagLayout в Java. Посмотреть как это сделано лучше всего в демках PFC.

    P.S. Может правда форум по PB попробовать попросить организовать у админа ? Я бы туда друзей с Украины затащил - PB там довольно таки распостранен и по опыту нам до них далеко.
    22 июл 03, 11:54    [270669]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    NNN
    Member

    Откуда:
    Сообщений: 2141
    2ASCRUS

    > Может правда форум по PB попробовать попросить организовать у админа ?

    Попытка не пытка. Для создания новых форумов есть два пути:
    Форум по Java
    Форум по Fox Pro?
    22 июл 03, 12:04    [270680]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Dmitry Belousov
    Member

    Откуда:
    Сообщений: 76
    sergei_p писал:
    Как в PB установить у элементов управления привязку к краю окна? Есть ли такая возможность вообще?


    При использовании PFC - сервис n_cst_resize. Посмотри в BOL.
    Без использования - отрабатывай событие resize.
    Hint: n_cst_resize как и многие другие сервисы PFC легко выделяются из библиотеки и могут использоваться сепаратно.

    PS. Даёшь форум по PBКартинка с другого сайта.
    22 июл 03, 12:09    [270684]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    Организовал тему Сбор подписей на открытие форума по Power builder на sql.ru. Думаю если много народу там выскажет свое желание админ смилостивиться над нами и сделает нас счастливыми. Тем более что PB одно из ведущих средств разработки клиентов и прям как то обидно, что он не предоставлен никак на этом замечательном сайте, давно уже переставшем быть просто SQL и более претендующего на название клиент-серверные технологии :)
    22 июл 03, 12:17    [270697]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Crip
    Member

    Откуда:
    Сообщений: 2490
    Попробуйте. Сколько было воплей о том, что не нужен форум по фоксу и что туда никто кроме женщин 30-50 лет ходит не будет ;) . Скоро по количеству постов форум перебьет все форумы по .NET вместе взятые
    22 июл 03, 12:18    [270702]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    Угу - я на это тоже внимание обратил :) Как всегда оказалось, что вопли о смерти фокса оказались преждевременными, как доказательство - активность форума по Фоксу :)
    22 июл 03, 12:22    [270706]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Dmitry Belousov
    Member

    Откуда:
    Сообщений: 76
    Коли NNN ещё здесь Картинка с другого сайта., попытаюсь осветить свою точку зрения на
    NNN писал:
    Ну а что, насчет недостатков, чего не хватает?


    Напрягает отсутсвие возможности работать напрямик с исходным кодом. Костыль, предложенный в восьмерке и девятке - "Edit source" -есть решение неудовлетворительное, ибо является просто экспортом / импортом вытащенным в оболочку.

    Кривая (неудобная) работа с API. Начинающие всегда с удивлением узнают, что любимой функции f() не существует, если среди параметров есть хоть одна строка. Как не вспомнить "There is no spoon..." Картинка с другого сайта.. А следует вызывать fa(), причём знать, в какой библиотеке она живет. Нет доступа к константам, структурам, битовым маскам, являющимся неотъемлемой частью любого API - Win32, например. Всё это конечно обходимо, но напрягает конкретно. Получение из внешней функции указателя на массив структур - житейское дело, скажем, в VC - драмма в трёх частях с прологом и эпилогом. Картинка с другого сайта. Возможно, NI, появившийся в девятке, как-то поможет жизни, пока не копал.

    При разрастании проекта > 20 Mб, т.е. вполне среднего, начинаются новые радости: сборка в *.exe+[*.dll] практически отпадает. Ну оооочень долго. Есть инкрементальная сборка, но это не панацея. На рынке присутствуют компиляторы для PB сторонних производителей, которые рекламируют свою продукцию: "У нас в 10 раз быстрей на большинстве проектов."

    PB (всех мне извесных модификаций) слишком корешится с Dr. Watson. А проще говоря, валится в самое неподходящее время. Иногда даже приходится забирать написанный скрипт в клипборд до сохранения...

    Могу ещё добавить, если мало.

    PS. Все недостатки перекрываются наличием неоспоримых достоинств - упоминавшимся здесь уже DataWindow / DataStore (не путать с гридами, абсолютно разные вещи) и возможностью с полпинка средствами самого продукта построить вполне сносную трехзвенку - Distributed PowerBuilder (по крайней мере до 9 версии).
    PS/2. Использую PB в качестве основного средства разработки уже шесть лет, поэтому журю на правах старого приятеля. Картинка с другого сайта.
    22 июл 03, 13:19    [270843]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Mykola
    Member

    Откуда:
    Сообщений: 615
    Привет всем из Украины.
    Некоторые мои мысли относительно вопроса.
    Я считаю что все средства хороши, если ты в них спец.
    Но предпочтение отдаю PowerBuilder.
    Хотя работал и сейчас иногда работаю на Delphi, Foxpro .

    Почему PowerBuilder
    1. производительность програмиста. (Попробуйте подключиться к базе и сделать выборку из таблицы и посмотреть все стили представления даных.
    И попробуйте сделать то же в Delphi, Foxpro)
    2. DataWindow - практически используя его одного при разработке проета Client/server можна запрограмировать очень многое,
    3. PFC - 1. возможность наследования библиотеки для уровня предприятия, отдела. Соответственно доработать на данных уровнях необходимые функции (для каждого из них). Что сразу дает разграничение прав.
    4. PFC - идет в открытом коде. Прекрасная возможность посмотреть как другие пишут код.

    Недостатки
    1. мало литературы. Ссылки на книги вам уже дали. Если кто не может скачать могу попробовать отослать компакт(есть опыт). Я имею ввиду книг на русском , украинском ... языках. Если посмотреть на amazon.com совсем противоположное.

    2. недоработанный Debug. На сегодня хочется побольше функций от него.
    особенно когда закрывает среду разработки.

    3. компиляция в exe . После необходимо полное тестирование проекта. замечены некоторые неточности в работе. Лучше компилировать в p-код как рекомендует фирма.

    4. выгрузка данных в офисные приложения. Без нее можна обойтись. Но думаю разработчики PowerBuilder должны это учесть.




    Это некоторые мои мысли в общих чертах.
    Если есть вопросы. Задавайте попробую ответить.
    22 июл 03, 13:38    [270882]     Ответить | Цитировать Сообщить модератору
     Re: Visual FoxPro 7 vs Power Builder 9  [new]
    Crip
    Member

    Откуда:
    Сообщений: 2490
    Нет доступа к константам, структурам, битовым маскам, являющимся неотъемлемой частью любого API - Win32, например. Всё это конечно обходимо, но напрягает конкретно. Получение из внешней функции указателя на массив структур - житейское дело, скажем, в VC - драмма в трёх частях с прологом и эпилогом.

    С этой частью API вызовов в VFP , тоже проблемы. Если в VB еще есть какая-то через уши поддержка структур, то в VFP их нет вообще. Есть только свои объекты и классы, не имеющие отношения к апишным структурам. Поэтому приходится обращаться через строковые буфера,для чего народом нарисованы нехилые классы преобразования.
    Я лично их не использую потому считаю , что гораздо проще обернуть нужный мне API вызов COM-объект на С++. Тоже самое с CallBack функциями и др. А вот многопоточность в фоксовом коде нормально не организуешь. Все равно будет отжирать процессор по полной в период выполнения...
    22 июл 03, 13:44    [270897]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить