При актуализиране
използвайки Quantum Grid 6
във формуляра се намира cxGrid, който показва данните от заявката към базата данни. за някои потребителски действия извън тази мрежа, заявката се актуализира. поставете след актуализацията курсора в мрежата върху същия запис, както беше преди - няма въпроси. но как да запазим същата позиция на прозореца за превъртане?
x := cxGridDBTableView.Controller.TopRecordIndex; . актуализация на данните . cxGr >
тогава позицията на лентата за превъртане се запазва, но флагът за преместване на превъртане се губи. това означава, че потребителят плъзга "каретката" на лентата за превъртане, след това идва съобщение от базата данни, данните са актуализирани, но лентата за превъртане вече не се движи. той ще трябва да кликне отново с мишката, което не е добре. и съобщенията ще идват често
добре, да кажем в случая с QuantumGrid, можете да използвате Controller.TopRecordIndex, като си играете по някакъв начин с това дали потребителят в момента превърта мрежата или не, да речем, използвайки същия GetCaptureControl. но някак си всичко това е тромаво и в стандартната vcl мрежа няма TopRecordIndex
Не вярвам някой тук да е имал този проблем.
напишете вашата мрежа
> [1] ari_9 (10/28/07 14:05) > това означава, че потребителят плъзга "каретката" на лентата за превъртане, тук от > Базата данни получи съобщение, данните бяха актуализирани, но лентата за превъртане вече е > не се движи.
Ужас. Бих убил програмиста. 8-)
Намерете по първичен ключ в набора от данни
да, аз също се смях, когато го пробвах за първи път, но смехът си е смях и за да избегнете това, след като получите събитие от базата данни, трябва да отложите актуализирането на съответния набор от данни, докато мрежата, свързана с него, спре да получава съобщения от мишката. ужас 8-)
и отново, и отново, няма да се уморя да повтарям. (със)
Искам да съхраня ПОЗИЦИЯТА НА ПРЕВЪРТАЩИЯ ПРОЗОРЕЦ в набора от данни.отвори набора от данни, има много записи. курсорът на набора от данни е на първия. потребителят, без да щраква върху действителните колони и съответно без да премества курсора на набора от данни, превърта мрежата до последния запис. как Locate ще помогне в този случай?
разгледайте внимателно изпълнението на TDBGrid.
> [6] ari_9 (29.10.07 11:27)
Направете прост бутон за опресняване и нарисувайте някакъв етикет с надпис "Данните в базата данни са променени. За да актуализирате, щракнете върху бутона."
диспечерите правят поръчки. всеки вижда данните на другите. средно една поръчка се прави за 3 секунди и се потвърждава след още 10-20. събитията се случват веднъж в секунда
Да, чета модули. докато стегнати (
ако някой има подобен проблем за Eh - тук има нещо http://www.sql.ru/forum/actualthread.aspx?t >
> [10] ari_9 (10/29/07 11:46 AM) > събитията се случват веднъж в секунда
Какво от това? А операторът например може да обработва 1 заявка на минута максимум. Какъв е смисълът да му показваш нови данни по-често?
няма въпроси, диспечерът е лице и няма да приеме поръчка за десетки. но когато избира коя поръчка да обработи (пусне за изпълнение), тоест всъщност просто гледа списъка и, копеле такова, понякога дори превърта 8-), тук е необходима актуализацията за ВСЯКО събитие. в противен случай той просто няма да види, че този се е появил преди две секунди, а друг диспечер го е взел преди една секунда
в случай, че отлагам опресняването на набора от данни, докато не пусне мишката върху мрежата, просто логично приемам, че е невъзможно да щракна върху реда на мрежата, без да завърша превъртането. опцията, че можете да плъзнете мишката и да изберете нещо успоредно със стрелките с enter, без да пускате мишката - това е за терапевта 8-). но всичко е някак. като сливици през ануса
>[12] ari_9 (10/29/07 12:13 PM) > но всичко е някак. като сливици през ануса
За мен вашият подход отговаря на това определение на 120%. Никой човек не може да вземе решение (изберете 1 от стотици опции), ако условията пред него се променят веднъж в секунда. Авиодиспечерите имат още по-лесни условия. Опитвате се да постигнете някакъв спекулативно-теоретичен идеал, а както знаете, пътят към ада е постлан с добри намерения.
от друга страна, данните не са актуализирани - диспечерът кликва върху поръчка, която вече е взета от някой друг и нейният статус вече е физически променен в базата данни, тоест просто нямахме време да я премахнем от мрежата - също лошо. И това е лошо както във версията на прозореца със съобщението, така и с "тихо игнориране". в първия случай ви принуждаваме да кликнете отново върху "Ok", във втория можете да се объркате какво се случва
в действителност вече има предишна версия на софтуера - там разработчикът, без да се занимава със събития, превъртания и други неща, просто затвори заявка за опресняване на таймера
както хората са свикнали. в действителност "висящите" поръчки рядко са повече от двадесет
> [14] ari_9 (10/29/07 13:06) > в първия случай ви принуждаваме да кликнете отново върху „Ok“,
О, горкият. По-добре програмно да натоварим сървъра на базата данни с актуализации, дори ако диспечерът чете вестник в тоалетната.
> [14] ari_9 (10/29/07 13:06) > в действителност "висящите" поръчки рядко са повече от двадесет
Сега също ще се окаже, че те се включват веднъж на час и един човек седи на обработка на непълно работно време. 8-)
> хората изглежда са свикнали с него Можете да свикнете с всичко. Това не е показател. Говорите с хората, след което посочвате опциите. Да правиш хората щастливи, без да ги информираш, е доста грозно.
> от друга страна, данните не са актуализирани - диспечерът кликва > Напоръчка, която вече е взета от някой друг и физически в базата данни > състоянието му вече е променено, тоест просто не сме имали време да премахнем > то от мрежата също е лошо. освен това е лошо във варианта на прозореца > със съобщението и с "тихо игнориране". в първия случай принуждаваме > щракнете върху "Ok" отново, във втория можете да се объркате, че > случва се
Тъй като някой е "уловил записа", когато друг оператор се опита да промени този запис, той ще покаже съобщение: "Записът се редактира от такъв и онзи." Това е напълно достатъчно. И когато програмата, която използвам, изведнъж започне да прави нещо без мое знание, я изхвърлям.
> ari_9 (10/29/07 11:30 AM) [7] > и отново, и отново, няма да се уморя да повтарям. (c) > Искам да запазя ПОЗИЦИЯТА НА ПРЕВЪРТАЩИЯ ПРОЗОРЕЦ на > данни.какво ви пречи да комбинирате прехода до желаната позиция с комбинацията от прозореца?
но като цяло, дъбовата организация на работа диспечерът не трябва да вижда всичко, ако има няколко като него той отговаря за своята област на работа и тогава има смисъл да се актуализира след операциите на ТОЗИ диспечер, а не на цялата тълпа
Е да . но ние ще натоварим сървъра с "леки" заявки в транзакции само за четене. ясно е, че всички действия за актуализиране ще се извършват отделно. и тогава с "отидох до тоалетната" тези заявки ще са само когато останалите активно редактират - ако всички са напуснали - няма да има събития от базата
СЛЕД като дадена операция бъде извършена от потребителя, тя естествено ще бъде опресняване. и ако диспечерът гледа екрана и чака поръчка с определени характеристики, които могат да бъдат сдвоени с някои вече взети за изпълнение. на нея, че десет минути всяка секунда натиска бутона "актуализация"?
>>като цяло лоша организация може би, но това не е в моята сферакомпетенции
както и да е, да се върнем на въпроса ми. тук се получи мнение от колеги, че когато потребител покаже някаква активност в мрежата - конкретно в моя случай, той може да я превърти и да отвори изскачащо меню, чието съдържание е обвързано с определен ред от набора от данни, не трябва дори да се опитвате да актуализирате нещо "на заден план"
интересно е друго. доколкото разбрах, всеки след опресняване на приложенията си прави Locate, за да се позиционира върху предварително избран запис. в обикновена мрежа няма TopRecordIndex и TopRowIndex. оказва се, че де факто стандартът е да се игнорира позицията на избрания запис в прозореца за превъртане след актуализиране на данните?
> интересно е друго. доколкото разбирам, всичко след опресняването в техните > приложенията Намерете до позиция на > предварително избран запис. в обикновена мрежа, без TopRecordIndex > и TopRowIndex не е. така че де факто стандартът е > игнорирайте позицията на избрания запис в прозореца за превъртане > след актуализиране на данните ? >
Де факто стандартът е да плъзнете извадка от 20-40 записа към клиента. Не 10 000 или 100 000.
> [18] ari_9 (10/29/07 13:58) > но нека не спорим за предметната област
Защо? Това е 90% от решението на проблема. Вие просто, IMHO, проблемът е в грешния модел.
> оказва се, че де факто стандартът е да се игнорира > избраният запис в прозореца за превъртане след актуализиране на данните? Фактическият стандарт е данните да се актуализират при поискване от потребителя. В същото време промяната на позицията на решетката е нормално и очаквано поведение на програмата.
каква разлика има, ако тези 40 записа не се поберат на височина, точно като сто хиляди :)
въпросът е затворен,проблема решен
> какво значение има, ако тези 40 записа не отговарят на всички > на височина, точно като сто хиляди :)
Написано е за DBGridEh, но мисля, че Mona може да се пренапише за cxGrid без никакви проблеми