Вверх ↑
Этот топик читают: Гость
Ответов: 5446
Рейтинг: 323
#16: 2006-10-31 15:23:55 ЛС | профиль | цитата
Chesh писал(а):
iarspider, да, с ошибками ситуация не очень... 2 да 3. Если есть наработки по поводу ошибок поделись плиз.


Да пожалуйста! Пока выдаётся толко код ошибки:
code_517


Ну и на закуску из C++ архивов

//==========
if (mysql_query(sql, buffer) != 0 || sql == NULL || mysql_errno(sql))
{
strcpy("Ошибка запроса данных пользователя", buffer);
ShowMySQLError(buffer);
return;
}
//==========
void ShowMySQLError(char* title)
{
char* errtext = strdup(mysql_error(sql));
MyMessageBox(title, errtext, STATUS_ERROR);
}

карма: 1

0
файлы: 1code_517.txt [1.5KB] [432]
Администрация
Ответов: 15294
Рейтинг: 1518
#17: 2006-11-01 21:18:56 ЛС | профиль | цитата
 TXSql=record
     _Open:TOpenSql;
_Close:TCloseSql;
_Query:TQuerySql;
_Exec:TQuerySql;
_DropTable:TQuerySql;
_EmptyTable:TQuerySql;
_ListTable:TQuerySql;
..... думаем... :)
end;
карма: 26
0
Ответов: 262
Рейтинг: 6
#18: 2006-11-02 06:50:40 ЛС | профиль | цитата
Dilma, все функции начиная с четвертой не нужны, все это делается через процедуру _Query обычными SQL коммандами.
А вот процедуры доступа к таблице результатов просто необходимы.

TQuerySql=function(const sql: string):boolean;
TGetRowSql=function(var Result: TData):boolean;
TErrorSql=procedure(var err: Integer; var ErrNm: string);

TXSql=record
_Open: TOpenDBSql; // открываем базу
_Close: TCloseSql; // закрываем
_Query: TQuerySql; // Выполняем запросы. SELECT, UPDATE, DROP TABLE, CREATE TABLE, INSERT,
// DELETE и прочие. не стоит делать процедуры на каждую SQL комманду.
// если произошла ошибка при выполнении запроса то =false
_GetRow: TGetRowSql; // возвращает строку результир. таблицы в виде MT цепочки. Равна false если последняя строка.
// работает по принципу FindNext. Альтернативное имя FetchRow.
_Error: TErrorSql; // возвращает номер и текст ошибки
end;
Обсуждаем...
карма: 0

0
файлы: 1code_524.txt [826B] [450]
Ответов: 2125
Рейтинг: 159
#19: 2006-11-02 11:09:37 ЛС | профиль | цитата
Ну, во-первых, если уж опять делать список указателей на функции (что по моему мнению каменный век) то
TQuerySql=function(const sql: string):boolean of object;
TGetRowSql=function(var Result: TData):boolean of object;
TErrorSql=procedure(var err: Integer; var ErrNm: string) of object;

А во-вторых, объясните мне всё-таки преимущества списка указателей на функции перед нормальным классом с виртуальными функциями
Не проще ли сделать общего предка с виртуальными функциями для всех компонент, являющимися базой данных?
карма: 1

0
Ответов: 9906
Рейтинг: 351
#20: 2006-11-02 11:32:29 ЛС | профиль | цитата
tsdima, не выпендривайся, а говори сразу - переходим на COM-технологию

Но одно безобразие в этом деле я таки нащупал
Как только мы составили таблицу vmt, то мы пристегнули ВСЕ методы класса и его предков до 10-го колена, независимо от их нужности.

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

[size=-2]------ Добавлено в 11:32
Да, про каменный век:
Если помнишь, то в COM-технологии не дается понятия виртуальных ф-й... Как мне показалось (возможно, что только показалось) потому, что в разных языках это делается не одинаково (не стандартизировано, в смысле) по результирующим кодам (они говорят, что - в бинарном виде)
карма: 9

0
Ответов: 262
Рейтинг: 6
#21: 2006-11-02 13:57:35 ЛС | профиль | цитата
tsdima писал(а):
если уж опять делать список указателей на функции

Dilma сказал, мы послушались ...
Про COM технологию неплохо написано здесь http://megalib.com/books/478/CHMFirstPage.htm
Там почти в самом конце есть статья "Общие сведения о COM". Кому интересно могут почитать. Весьма доходчиво объяснили. Все вроде бы и просто
карма: 0

0
Ответов: 2125
Рейтинг: 159
#22: 2006-11-02 14:06:01 ЛС | профиль | цитата
пристегнули ВСЕ методы класса и его предков
Ну не все, а только виртуальные, коих обычно не так много, и они обычно все используются. Можно подумать, если мы создадим вышеописанный record и присвоим адреса функций, то мы "пристегнём" только используемые...
Если помнишь, то в COM-технологии не дается понятия виртуальных ф-й
Потому-что у интерфейса там все функции виртуальные Интерфейс - это указатель на объект, первое поле которого - указатель на vtbl/vmt.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#23: 2006-11-02 18:23:46 ЛС | профиль | цитата
Звучит интересно:
Ну не все, а только виртуальные

Потому что у интерфейса там все функции виртуальные


Про первое поле я знаю. Вот только не факт, что на некотором КОМПИЛЯТОРЕ указатель на vmt - первое поле.
Скажем Кладов, чтобы это было так с наследниками TObj, ввел еще одно безобразие - _TObj.
Т.е., возможны варианты...
Но это - мелкие технические детали, пройденные многими до нас как на Дельфи, так и на чем-нибудь еще.

Главное - объем подключаемого.
И естественно, если это разговор лишь только о БД - то сразу становится неинтересно.
Мне гораздо интереснее аспект перехода на единую технологию и с картинками, и со стримами...
Да и вообще, надо все наши TData "ссылочного" типа переводить на data_object со своими интерфейсами...

И вот тут, пускать на самотек объем "пристегивания" - значит, быть таким же умным, как и Билл
карма: 9

0
Ответов: 2125
Рейтинг: 159
#24: 2006-11-02 20:27:58 ЛС | профиль | цитата
Звучит интересно:
Я же написал "интерфейса". Естесственно, все методы интерфейса должны быть пристёгнуты, никто же не знает, какие методы будут использоваться, а какие нет, на то он и интерфейс. А вот что из огромной библиотеки используют эти методы интерфейса, только это и пристегнётся.
не факт, что на некотором КОМПИЛЯТОРЕ указатель на vmt - первое поле
В каком поле этот vmt - неважно, главное, что указатель на интерфейс - это указатель на это поле, и получив этот указатель вместо Self объект уже сам должен разбираться, где у него данные - выше или ниже, то есть скорректировать указатель до Self. А это, как раз, забота компилятора, умеющего делать интерфейсы.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#25: 2006-11-02 20:40:00 ЛС | профиль | цитата
А вот что из огромной библиотеки используют эти методы интерфейса, только это и пристегнётся.

А вот я интересуюсь, нафига там это все остальное, если общение идет ТОЛЬКО через методы интерфейса. И если оно не "пристегнется", то методы интерфейса это остальное не затрагивает ведь.

Смысл-то в чем:
  1. Наша схема использует 2 интерфейсных метода из 5.
  2. В нашу прогу "пристегнется" и все, что затрагивают оставшиеся 3 метода.
  3. Это - не есть верх интеллекта. Надо придумать выход.
карма: 9

0
Ответов: 2125
Рейтинг: 159
#26: 2006-11-02 21:55:07 ЛС | профиль | цитата
Наша схема использует 2 интерфейсных метода из 5
Тогда она должна использовать интерфейс, в котором есть только эти 2 метода. Выход - сделать несколько интерфейсов с разным набором методов. Вот только выбор интерфейса должен происходить во время компиляции. Таким образом, по аналогии с ReadArray, нужно иметь ReadDatabase, но не одну, а на каждый набор методов: ReadDatabase_Db2, ReadDatabase_Db5. А компонент Database имея одну var-точку Database должен предлагать несколько функций запроса этой переменной: _var_Database_Db2, _var_Database_Db5 возвращающие соответствующие интерфейсы. Обобщив сказанное делаем вывод: среда должна поддерживать типы точек. То есть, сейчас: одна точка - одна функция, возвращающая/передающая тип TData. А должно быть: одна точка - несколько функций, для каждого типа данных. Соответственно и несколько типов событий: THI_Event_Db2,THI_Event_Db5. Если data-точка имеет тип THI_Event_Db2, то связываем её с _var_Database_Db2, а если THI_Event_Db5, то с _var_Database_Db5. Это уже в CodeGen учитывать. Но он должен получить от среды тип точки. Var и Work точки должны иметь список поддерживаемых типов, а Data и Event точки - требуемый тип. Если требуемого типа нет в наличии - не соединять такие точки. Для совместимости - все компоненты сейчас предлагают и требуют тип TData.
карма: 1

0
26
Сообщение
...
Прикрепленные файлы
(файлы не залиты)