Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» Вопросы по Delphi (версии 2009, 2010 Weaver, 2011 Fulcrum)

Автор: Frodo_Torbins
Дата сообщения: 11.07.2012 15:11
neznayka3
Если основной модуль нельзя модифицировать, то поможет WaitForInputIdle.
Автор: neznayka3
Дата сообщения: 31.07.2012 19:44
есть не редактируемый набор данных, и процедура типа
Код:
procedure EnableActionForOrders;
begin
if <DataSet>.RecordCount=0 then
begin
<Action>.Enabled:=false;
end
else
begin
<Action>.Enabled:=true;
end
end;
Автор: A_V
Дата сообщения: 31.07.2012 22:01
neznayka3
проще всего в Action.OnUpdate, либо на GridView.DataController.OnDataChanged (но оно будет происходить при загрузке на каждую запись грида).
и проверять не через DataSet.RecordCount, а GridView.ViewInfo.VisibleRecordCount
Автор: eddoc
Дата сообщения: 03.08.2012 13:47
Комрады, подскажите.

Нужно из-под клиента запускать консольку в командной строке с параметрами. Чем лучше воспользоваться?

DXE, Win7 x64
Автор: diablist
Дата сообщения: 03.08.2012 21:22
eddoc
Ну можно так

Цитата:
ShellExecute(0, 'runas', '"cmd.exe"', PWideChar('параметры'), nil, SW_SHOWNORMAL);

runas - если запуск нужно от имени админа
Автор: eddoc
Дата сообщения: 04.08.2012 00:12
diablist
Ага, спасибо. Я наконец-то вспомнил когда-то попутно читанное.

CreateProcess (если я правильно помню, его в своих унутрях и использует ShellExecute) и WaitForSingleProcess.

Пошел читать...
Автор: eddoc
Дата сообщения: 07.08.2012 15:53
Вот интересно. [more=В этом куске кода]
Код: //ApplicationExe - полный путь к приложению
//ParamExe - "правильная" строка с параметрами

CmdLine:= Format('"%s" %s', [ApplicationExe, ParamExe]);

FillChar(SI, SizeOf(SI), 0);
SI.cb := SizeOf(SI);

if CreateProcess(PChar(ApplicationExe),PChar(CmdLine),0,0,False,CREATE_NO_WINDOW,0,0,SI, PI) then
begin
// Опционально: ждём завершения процесса
WaitForSingleObject(pi.hProcess, INFINITE);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
end;
Автор: ant0ni02004
Дата сообщения: 08.08.2012 12:52
eddoc
какие параметры вы этому коду ему передаёте? ведь батник не сам по себе запускается, а через cmd.exe (который и читает выход от gbak-а)
Автор: MagistrAnatol
Дата сообщения: 08.08.2012 13:31
Подсобите с такой проблемой - пытаюсь нажать на кнопку через TWebBrowser в C++Builder XE2
вот код странички

Код:
<INPUT value="Войти" class="inp2" type="button" onclick="on_submit()" >
.................
<SCRIPT>function on_submit(){if (document.getElementById("client").value == "") {alert("Введите логин для входа в систему!");return false;}if (document.getElementById("password").value == "") {alert("Введите пароль для входа в систему!");return false;}login.submit();_gat._getTracker('UA-29905618-1')._trackEvent('Общие','Вход','');_gat._getTracker('UA-30154094-1')._trackEvent('Общие','Вход','');}document.getElementById("ViewerN").value=window.navigator.userAgent.substring(window.navigator.userAgent.indexOf("MSIE"),window.navigator.userAgent.indexOf(";", window.navigator.userAgent.indexOf("MSIE")));var loc=""+location;document.getElementById("port").value=loc.substring(loc.lastIndexOf(":")+1, loc.indexOf("/", loc.lastIndexOf(":")));document.getElementById("ClOffset").value = - (new Date()).getTimezoneOffset();function keyevent(e) // submit key{if (e.keyCode == 13) // 13 = enter key{on_submit();}} </SCRIPT>





мой код

Код:
TComInterface<IHTMLDocument2> pDoc;
TComInterface<IHTMLElementCollection> pColl;
TComInterface<IDispatch> pTmpDisp;
TComInterface<IHTMLInputElement> pElement;
TComInterface<IHTMLElement> pButtomElement;
TComInterface<IDispatch> pDisp;

AnsiString InmemberName = "client";
WideString InmemberData = AdvEditBtn2->Text;
AnsiString Inpassword = "password";
WideString InpasswordData = AdvEditBtn3->Text;
AnsiString InpCode = "code";
WideString InpCodeData = AdvEditBtn4->Text;

AnsiString SubmitButton = "inp2";

if ( SUCCEEDED (browser->Document->QueryInterface(IID_IHTMLDocument2, (LPVOID*)&pDoc)))
{
if ( SUCCEEDED (pDoc->get_all(&pColl)))
{

...
if ( SUCCEEDED (pColl->item(TVariant(WideString(SubmitButton)), TVariant(0), &pDisp)))
{
pButtomElement = pDisp;
ShowMessage(1);
pButtomElement->click();

}



данные в форму заносятся верно и если нажать кнопочку ручками все нормально, но если
давлю программно - получаю Assertion failed: intf!=0, file=c:\...\utilcls.h line 2374

пробовал и AnsiString SubmitButton = "submit";
таже байда.
Как правильно нажать на такую кнопку?, у нее получается нет имени????
Ну и походу вопрос - как прочитать каптчу - 4 цыфирки?
Автор: eddoc
Дата сообщения: 08.08.2012 16:22
ant0ni02004

Цитата:
какие параметры вы этому коду ему передаёте? ведь батник не сам по себе запускается, а через cmd.exe (который и читает выход от gbak-а)


Само собой, я имел ввиду запуск cmd.exe из-под батника

Если имелись ввиду параметры в батнике, то командная строка выглядит примерно так

Код:
set isc_user=SYSDBA
set isc_password=masterke

e:\Portable_firebird\Firebird\Firebird_2_1\bin\gbak -c e:\Databases\test.fbk e:\temp\new_test.fdb -v -y e:\temp\log_test_db.txt -z
Автор: neznayka3
Дата сообщения: 10.08.2012 14:13
про Dataset. как можно отменить изменения в записи только у одного поля?
Автор: eddoc
Дата сообщения: 11.08.2012 12:05
neznayka3

Цитата:
про Dataset. как можно отменить изменения в записи только у одного поля?

По логике, никак. Как выход, изменять на клиенте искомое поле только по условию. Либо, менять в текущей транзакции только ЭТО поле
Автор: eddoc
Дата сообщения: 11.08.2012 19:41
Вопрос по тредам и отрисовке VCL из потока.

Вот в этом [more=тестовом коде]
Код: TMyThread = class(TThread)
private
{ Private declarations }
q: Integer;
str: string;
procedure Update;
public
{ Public declarations }
k: Integer;
protected
procedure Execute; override;
end;

var
Form1: TForm1;
k: Integer;
MyThread: TMyThread;
BoolFlag: Boolean;
ListDisabled : pointer = nil;

implementation

//=============================
procedure TForm1.BtnRunClick(Sender: TObject);
begin
MyThread:=TMyThread.Create(False);
MyThread.Priority:=tpLower;
MyThread.FreeOnTerminate:=true;
BoolFlag:= True;
BtnRun.Enabled:= False;
BtnStop.Enabled:= True;
k:= 1;
end;

{ TMyThread }

procedure TMyThread.Execute;
var TimeCounter: Cardinal;
FrmClr: TColor;
begin
inherited;
q:= 1;
FrmClr:= Form1.Color;

//меняем цвет, чтоб подлежащая форма отличалась от wait-формы
Form1.Color:= clMoneyGreen;

TimeCounter:= 0;
ListDisabled:= DisableTaskWindows(Form2.Handle);

Form2.Show;//покажем wait-форму

//булев флаг взведен BoolFlag = True
while BoolFlag do
begin
Synchronize(Update);
Sleep(100);
Inc(q);
if q > 4 then q:= 1;
Inc(TimeCounter);
str:= IntToStr(TimeCounter);
if TimeCounter > 50
then Form1.BtnStopClick(Self);//здесь скидываем булев флаг BoolFlag:= False;
end;


MyThread.Terminate;
EnableTaskWindows(ListDisabled);
ListDisabled:= nil;

Form2.Hide;
Form1.Color:= FrmClr;
end;

//========================================
procedure TMyThread.Update;
begin

if q = 2 then
begin
Inc(k);
if k > 4 then k:= 1;
end;

with Form2 do
begin
img2.Picture.LoadFromFile(ExtractFilePath(Application.ExeName) + '\pict_small\' + IntToStr(q) + '_small.png');
Lbl2.Caption:= 'Подождите, процесс движется ';
Lbl3.Caption:= 'TimeCounter = ' + str;

//отображаем многоточие
case k of
2: Lbl2.Caption:= Lbl2.Caption + '.';
3: Lbl2.Caption:= Lbl2.Caption + '..';
4: Lbl2.Caption:= Lbl2.Caption + '...';
end;
end;
end;
Автор: Frodo_Torbins
Дата сообщения: 13.08.2012 12:11
eddoc
Цитата:
А разве отображаемая там консолька не есть cmd.exe?
Нет. Это окошко автоматически создает винда, для каждого консольного приложения, если оно не наследует родительские пайпы. По крайней мере, если это обычное консольное приложение.

По поводу потоков: из потока вообще нельзя обращаться к VCL, а у вас там нормальная синхронизация только в одном месте организована.
Автор: eddoc
Дата сообщения: 13.08.2012 15:51
Frodo_Torbins

Цитата:
По поводу потоков: из потока вообще нельзя обращаться к VCL

а если сильно нужно?

Вообщем, я тут поэкспериментировал. Для начала переопределил свойство окна в методе [more=CreateParams]
Код: procedure TForm2.CreateParams(var Params: TCreateParams);
begin
inherited;
with Params do
Style := Style
and (not WS_CAPTION)
// and (not WS_THICKFRAME)
or WS_POPUP;
end;
Автор: neznayka3
Дата сообщения: 14.08.2012 11:53
недавно прочитал мнение, что нельзя хранить тексты sql запросов на клиенте. где тогда хранить, в ресурсах?
Автор: Frodo_Torbins
Дата сообщения: 14.08.2012 12:07
eddoc
Цитата:
а если сильно нужно?
Если сильно нужно, то юзаем Synchronize. У вас он используется далеко не всюду, где должен.

neznayka3
Мне кажется для этого вюхи предназначены: Представления (VIEW) в MySQL.
Автор: JAPWork
Дата сообщения: 14.08.2012 13:11
neznayka3

Цитата:
нельзя хранить тексты sql запросов на клиенте

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

Автор: Samotek
Дата сообщения: 14.08.2012 13:20
Frodo_Torbins

Цитата:
Мне кажется для этого вюхи предназначены:

а если запрос с разными колонками? Например нужны только розничные цены или остатки только из определенного подразделения? То есть запрос создается динамически. Столько вьюх не напишешь.
Автор: eddoc
Дата сообщения: 14.08.2012 13:45
Frodo_Torbins

Цитата:
Если сильно нужно, то юзаем Synchronize. У вас он используется далеко не всюду, где должен.

А как по-вашему выглядел бы идеальный код в моем случае?
Автор: neznayka3
Дата сообщения: 14.08.2012 13:45
Frodo_Torbins
выборки напрямую из таблиц у меня нет, только view & functions.
JAPWork
на sqlru тема зашла, за что руки разработчикам отрывать) начали с with, правда не понял, почему им лучше не пользоваться, только во время отладки разве что неудобно бывает. тему сходу сейчас не нашел.

Цитата:
И что означает "нельзя на клиенте"

текст запроса не изменить, без перекомпиляции. иногда имя колонки/функции/кол-во параметров/итд изменилось или еще чего. во время разработки такое постоянно.
Автор: A_V
Дата сообщения: 14.08.2012 13:47
neznayka3
JAPWork
возможно имелись ввиду трехзвенки (DataSnap), но даже если брать clinet-server, то бывает удобнее держать запросы во вьюхах, хранимках (mssql), объектах (oracle) или даже в своих таблицах.

удобнее например тем, что для изменения запроса (напр. добавление поля в список) не нужно пересобирать и раскладывать клиент (есть например реализации, в которых даже клиентские формы строятся на сервере). также удобно то, что в случае изменения схемы данных объект на сервере сразу станет инвалидным (oracle), а не отвалится в момент использования (вобщем классическое раннее/позднее связывание).
могут быть и варианты с использованием нескольких субд, когда клиент знает наименования процедур и полей, но то что внутри - его не касается.
еще из минусов хранения текстов запросов на клиенте в dfm - их неудобно мерджить в системах контроля версий. если же тексты писать в коде, то постоянная конкатенация строк тоже выглядит не очень. еще ORM реализации есть, живьем на delphi их правда не встречал...

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

Добавлено:
neznayka3
ну вот, опередил пока набирал, именно что
'текст запроса не изменить, без перекомпиляции. иногда имя колонки/функции/кол-во параметров/итд изменилось или еще чего'
Автор: JAPWork
Дата сообщения: 14.08.2012 14:45
neznayka3
A_V

Цитата:
текст запроса не изменить, без перекомпиляции.

Как правило, любые запросы к базе данных так или иначе связаны с некоторой последующей визуализацией их результатов. Красивые гриды, поля на формах, отчеты, наполовину заполненные экраны для дальнейших, уточняющих запросов и так далее. Поэтому я не слишком верю в не влекущие за собой перекомпиляции программы изменения в именах "колонок/функций, кол-ва параметров". Те частные случаи, в которых при таком подходе можно обойтись без перекомпиляции, настолько редки, что обсуждения не заслуживают. В самом же общем случае (типовой пример - пользователь попросил обеспечить указание периода за который следует получить отчет) - никуда не денетесь, будете втискивать на форму поле с датой, а то и с диапазоном дат.
Хранение в формах - не приветствую. Конкатенация строк, конечно, выглядит не слишком, это так. Но во всем остальном - вполне. Хранение на сервере - лучше, но панацеей от перекомпиляции вовсе не является.
Да и стремно. Вьюхи вроде бы как во многом созданы для того, чтобы развязать логическую и физическую модель, спрятать особенности реализации. А мы теперь навернем еще один уровень абстракции, чтобы уйти от особенностей вьюх. Конечно, я встречал попытки трехуровневого метамоделирования, когда метаданные одного уровня описывали метаданные другого уровня и так далее. Работоспособность таких монстров была, мягко говоря, слишком близка к полной неработоспосбности. Про сопровождение такого кода я уже и не говорю...
Автор: A_V
Дата сообщения: 14.08.2012 15:08
JAPWork

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


не настолько уж и редки, в типичных КИС, почти половина форм - это списочные, т.е нужно получить список (грид) каких-то сущностей, предварительно его отфильтровав. (аотом эл-ты этого списка редактируются в отдельной форме). при хранении запросов на сервере, такая универсальная списочная форма на клиенте программируется всего один раз.


Цитата:
В самом же общем случае (типовой пример - пользователь попросил обеспечить указание периода за который следует получить отчет) - никуда не денетесь, будете втискивать на форму поле с датой, а то и с диапазоном дат.

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


Цитата:
Хранение на сервере - лучше, но панацеей от перекомпиляции вовсе не является

иногда является самой что ни наесть панацеей, когда, как я выше упоминал, формы рисуются тоже на стороне сервера. (econtrol designer+pascal script, знаю такие примеры). другой вопрос, нужно ли это такой ценой..

но даже при обычном подходе хранение только запросов на сервере может сильно уменьшить кол-во сборок (списочные формы, отчеты, просто небольшое изменение логики получения данных)
Автор: JAPWork
Дата сообщения: 14.08.2012 15:39
A_V

Цитата:
иногда является самой что ни на есть панацеей. ... другой вопрос, нужно ли это такой ценой..

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


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

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

Наиболее полная аналогия - это запросы с параметрами. Можно долго говорить о том, что хорошо проработав предметную часть можно все запросы снабдить десятком параметров, чтобы исключить необходимость какого-либо внесения изменений в запросы в дальнейшем. Увы... Через год эксплуатации с неизбежностью выяснится.. Ну - Вы поняли...
Автор: A_V
Дата сообщения: 14.08.2012 15:44
JAPWork

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

Не одна пустая форма, но отчеты и списочные формы держать на сервере вполне реально. Просто п(р)оверьте
Автор: XPerformer
Дата сообщения: 14.08.2012 16:11
A_V
А и много ли в серьезном проекте списочных форм, не связанных друг с другом и другими документами, для которых не нужна специализированная форма редактирования? не настолько, чтобы возводить их в правило
Автор: A_V
Дата сообщения: 14.08.2012 16:21
форму редактирования, да, лучше делать в дельфе, но ее привязка к списочной форме может настраиваться на сервере
Автор: XPerformer
Дата сообщения: 14.08.2012 16:22
A_V
то есть на сервере прописывать какие комбобоксы должны быть и прочие вложенные гриды?
Автор: A_V
Дата сообщения: 14.08.2012 16:45
XPerformer
речь о гриде списочной формы? если да, то комбобокы тоже могут настраиваться на сервере (в списке 'имя поля -- имя view').
вложенные гриды= master-detail в cxGride или подобном? тоже можно описать.
более того, можно сделать такое описание удобным

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172

Предыдущая тема: Установка копоненты ZipTV


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.