|
Notes |
|
|
(0010935)
|
|
zed
|
28-03-2013 16:29
(edited on: 28-03-2013 16:30) |
|
|
|
|
(0010936)
|
|
zarius
|
|
29-03-2013 06:38
|
|
Для примера реализации добавил небольшой скрипт "Послать сообщение SAS" (исходники + exe).
Резализован с помощью AutoIt v3 (http://www.autoitscript.com/autoit3/)
Примеры запуска:
("послать сообщение SAS.exe" MSG "1;58.594136;49.684498;17") - переход к координате с масштабом 17
("послать сообщение SAS.exe" ?) - выведет хелп по параметрам запуска |
|
|
|
(0010937)
|
|
Garl
|
|
29-03-2013 11:08
|
|
|
может ещё прилепить переключение на карту\слой? |
|
|
|
(0010938)
|
|
zarius
|
|
29-03-2013 11:27
|
|
хм... как вариант можно... только как передавать ИД карты/слоя?
а вообще практическое применение переключения карты/слоя извне есть? |
|
|
|
(0010939)
|
|
Garl
|
|
29-03-2013 11:44
|
|
Передавать по уникальному GUID
практическое: перейти к координате х.у на карте Z
|
|
|
|
(0010940)
|
|
zarius
|
|
29-03-2013 12:59
|
|
|
вообще думаю будет полезно... посмотрю в эту сторону... |
|
|
|
(0010941)
|
|
zed
|
|
30-03-2013 21:01
|
|
|
А ещё, может оказаться полезным передавать команду на начало загрузки выделенной области. Т.е. передаётся зум, GUID и, скажем, путь до hlg с выделенной областью. Таким образом, можно будет автоматически стартовать загрузку сразу для нескольких зумов. |
|
|
|
|
|
Есть подозрение, что передавать команду на начало загрузки выделенной области надо через какой-нибудь файл типа sls, ибо число параметров при загрузке области дюже велико, чтобы их все запихать в строку, да и меняться оно может, а функциональность sls и так их (все параметры сессии загрузки) замечательно покрывает. Хотя конечно в команде можно перекрыть Zoom и Guid. |
|
|
|
(0010985)
|
|
zarius
|
|
04-04-2013 09:40
|
|
В процедуру приема сообщений из других приложений добавил отработку новых действий:
5. изменение карты/слоя по GUID (в случае со слоем - активация/деактивация в зависимости от текущего состояния)
6. установка признака видимости меток на карте (1 - видимы; 0 - не видимы) |
|
|
|
(0010987)
|
|
zarius
|
|
04-04-2013 09:47
|
|
Вот сейчас думаю как сделать так чтобы с помощью SAS "снимать" необходимую координату. Например, поступает сообщение с режимом "снять координату" - в SASе устанавливается некий флаг ожидания двойного щелчка мыши. После выполнения оного SAS инициирует пересылку этих координат так же через SendMessege обратно (в этом случае необходимо передавать и хранить в SASе хэндл вызывающего приложения).
Может данную ситуацию можно отработать другим способом?
К слову, сейчас я ее отрабатываю через установку временной метки на карту - но не очень нравится интерактивность данного действа. |
|
|
|
|
>как сделать так чтобы с помощью SAS "снимать" необходимую координату
>устанавливается некий флаг ожидания двойного щелчка мыши
>инициирует пересылку этих координат так же через SendMessege
>хранить в SASе хэндл вызывающего приложения
Вы это всё реально хотите? Пулреквест не примут, я гарантирую это. Потому что это бред.
Максимум что получится (если vdemidov будет в хорошем настроении) - PostMessage на хэндл из WM_COPYDATA, а упаковать текущие координаты в 2 Integer-а можно просто умножив их на $B60000 и округлив до целого, ошибка на экваторе будет меньше сантиметра:
// $B60000 = 11927552
// максимум = 2146959360 = 7FF80000
// квант = 0.000000083839500343406
// при длине экватора 40075км одному кванту соответствует 9мм на экваторе
c_COORD_to_INT = $B60000;
зы. Надо будет ещё сделать команду типа
M/CAT_NAME/MARK_NAME/IMG_NAME/kml/56.711,60.718,125
для создания или обновления метки (по аналогии с тем, что я делал для внутреннего httpd). Но это я сам сделаю, когда этот пункт закроется, чтобы лишний раз не ковыряться, потом если надо будет - перетащите. |
|
|
|
(0010990)
|
|
zarius
|
|
04-04-2013 10:17
|
|
PostMessage тоже неплохо :) спасибо за идею
По работе с метками думал, но пока решил повременить - сейчас работаю напрямую через БД SQLite (еще раз спасибо за реализацию). Кстати, есть ли новости на этом плане? Можно ли надеяться что эти изменения войдут в основную ветку? |
|
|
|
|
>Можно ли надеяться что эти изменения войдут в основную ветку?
Надеяться можно )) |
|
|
|
|
|
Я бы все-таки посоветовал переделать идентификаторы операций с чисел на осмысленные слова. А еще лучше реализовать что-то типа параметров коммандной строки и использовать этот же код и при запуске. |
|
|
|
(0010993)
|
|
zarius
|
|
04-04-2013 10:53
|
|
>Я бы все-таки посоветовал переделать идентификаторы операций с чисел на осмысленные слова.
При наличии большого числа режимов - действительно имеет смысл, так что согласен.
например:
goto = 1. переход к координате;
nav = 2. навигация на координату;
gotonav = 3. переход к координате с навигацией;
zoom = 4. изменение зума
map = 5. изменение карты/слоя по GUID
marks = 6. установка признака видимости меток на карте
mark = добавление/удаление/обновление метки
нормально? или есть что поправить? |
|
|
|
(0010994)
|
|
zarius
|
04-04-2013 10:58
(edited on: 04-04-2013 11:03) |
|
>А еще лучше реализовать что-то типа параметров коммандной строки и использовать этот же код и при запуске.
хм.. сомневаюсь что объединение с режимом запуска из ком. строки будет оправданным, т.к. некоторых результатов можно достичь только за несколько вызовов. С командной же строкой мы ограничены одним вызовом. Хотя возможно это когда-нибудь пригодиться.
P.S. кроме того при запуске этих же результатов можно достичь правкой ini
|
|
|
|
(0010995)
|
|
zed
|
|
04-04-2013 11:05
|
|
|
Как вариант, можно выдумать свой файл сценариев и передавать его на вход при запуске. Но задача сильно усложняется. |
|
|
|
|
Лучше сделать как параметры в командной строке:
--move=({lon},{lat})
--zoom={value}
--navigation=({lon},{lat})
--map={GUID}
--show-placemarks={0/1}
--insert-placemark=("{name}";{lon},{lat};....)
И тд.
Тогда их можно будет спокойно комбинировать без создания таких странных гибридов как gotonav.
Можно будет сделать передачу их из коммандной строки заменив существующую обработку
Можно будет сделать что бы при запуске второй копии САСа с параметрами, она не стартовала а просто передавала команду уже запущенной версии. |
|
|
|
|
1. gotonav реально отдельный нужен, нельзя парой goto+nav обойтись?
2. marks как-то непонятно, что show или hide или что это visibility.
3. mark - имеет смысл разделять (создание+обновление) и (удаление). это так сказать разные бизнес-процессы. и накосячить шансов меньше. |
|
|
|
|
> некоторых результатов можно достичь только за несколько вызовов
В том варианте что предлагаю можно несколько команд за раз передать
> P.S. кроме того при запуске этих же результатов можно достичь правкой ini
Прямая правка чужого конфига не самый лучший вариант - названия параметров могут поменятся в любой момент так как они не относятся к публичному интерфейсу программы. |
|
|
|
(0010999)
|
|
zarius
|
|
04-04-2013 12:00
|
|
>1. gotonav реально отдельный нужен, нельзя парой goto+nav обойтись?
Уже тоже думаю, что не нужен. Лучше отдельно goto+nav
Остальные пункты тоже поддерживаю.
>Можно будет сделать что бы при запуске второй копии САСа с параметрами, она не стартовала а просто передавала команду уже запущенной версии.
"ЗА" двумя руками! :) Это реально решит проблему, когда в сторонних приложениях нет возможности создать указатель на "COPYDATASTRUCT". |
|
|
|
|
> "ЗА" двумя руками! :) Это реально решит проблему, когда в сторонних приложениях нет возможности создать указатель на "COPYDATASTRUCT".
Ну так вперед. Только хорошо бы новый парсер комманд вынести в отдельный класс, который будет получать необходимые для работы интерфейсы в конструкторе, но это всегда успеется. |
|
|
|
(0011001)
|
|
zarius
|
|
04-04-2013 12:17
|
|
>Ну так вперед.
Начну копать в этом направлении.
Думаю что надо предусмотреть что то вроде --handle={win_handle} чтобы можно было команды посылать направленно. |
|
|
|
|
>handle={win_handle}
OMG. Что это? Если это хендл окна клиента - то почему вообще такая дурная мысль возникла, что клиент у саса будет один с одним окном?
>чтобы можно было команды посылать направленно
Надо не команды посылать направленно, а отвечать только тому клиенту, который запросил данные (если в данных есть hwnd - ради бога). Совершенно стандартный клиент-серверный подход. Клиент шлёт запрос, а сервер на него отвечает. Близкая аналогия - протокол FTP. |
|
|
|
(0011007)
|
|
zarius
|
05-04-2013 05:19
(edited on: 05-04-2013 05:20) |
|
Попробую пояснить: если организовать выполнение команд через командную строку и при этом "сделать что бы при запуске второй копии САСа с параметрами, она не стартовала а просто передавала команду уже запущенной версии" - как будет осуществляться поиск этой уже запущенной версии? А если в текущий момент запущено более одной копии САС? Будет неприятно, если, например, метка добавиться не в ту копию САСа. Имхо, если хэндл передан - команду транслировать в него, иначе - осуществлять поиск по заголовку окна.
Или я как то не так понял замысел?
|
|
|
|
|
>сделать что бы при запуске второй копии САСа с параметрами, она не стартовала а просто передавала команду уже запущенной версии
Это слишком глобальная задача, чтобы её тут решать. И в такой формулировке решение её бессмыслено. Передача парамеров нужна для блокированных меток в SML? Так давайте проблему решать, а не гланды рвать через анус. А если другая версия саса работает по другой базе меток SML? Почему вообще сас должен слать командную строку, а не какая-то другая микроEXEха, специальным образом обученная для этого, в том числе обученная на поиск нужного саса?
>как будет осуществляться поиск этой уже запущенной версии?
Давайте этот вопрос оставим за рамками этой темы. Я вам могу сразу написать, что однозначно 100% работающего решения нет, даже регистрация широковещательного сообщения и рассылка его не всегда спасут. А handle у окна в процессе жизни приложения может меняться.
>Будет неприятно, если, например, метка добавиться не в ту копию САСа
В настоящий момент метка либо не добавится вообще в случае блокированного SML, либо без проблем добавится во всех остальных случаях. Как она может добавиться не в ту копию? Если что-то будете делать с метками - тут неважно, по какой причине она не добавилась, или почему добавилась. Просто пробуем добавить, если обломились - ошибка.
>иначе - осуществлять поиск по заголовку окна
шутить изволите? ну найдёте 25 сасовых окон - кому слать будемте? |
|
|
|
(0011009)
|
|
zarius
|
|
05-04-2013 06:49
|
|
>Почему вообще сас должен слать командную строку, а не какая-то другая микроEXEха
Сейчас у меня так и работает: за пересылку отвечает откомпиленный скрипт. Но vdemidov предложил перенести этот функционал в САС и мне это понравилось - возрастает удобство использования этого функционала. Или все таки в папку с САСом класть некий exe для выполнения этих команд? Давайте определяться...
>А если другая версия саса работает по другой базе меток SML?
А какая разница с какой базой работает вызываемая версия САС, если работать с метками будет именно она своими локальными механизмами?
>ну найдёте 25 сасовых окон - кому слать будемте?
Первому попавшемуся. А вот если задача будет стоять переслать конкретному экземпляру САС из 25 запущенных - это задача уже для того, кто команды посылает - для этого и необходим хендл конкретного САСа в командной строке. Имхо, иначе задачу не решить - либо экземпляр один и мы с ним работаем, либо, если предполагается несколько экземпляров - работаем с заранее определенным - и данную задачу надо решать на уровне приложения, откуда вызывается новый экземпляр САСа с командной строкой. |
|
|
|
(0011010)
|
|
zarius
|
|
05-04-2013 07:05
|
|
|
Возможно мы разговариваем о разных вещах и не понимаем друг друга... опишу как я понял идею vdemidov'а: при запуске САСа с командной строкой - САС определяет что за команды и что с ними делать - либо запускаться самому в обычном режиме с выполнением этих команд, либо передать данные команды другой копии уже запущенного САСа через WM_COPYDATA с последующим завершением работы по окончании передачи команд. |
|
|
|
(0011011)
|
|
zarius
|
|
05-04-2013 07:10
|
|
>ну найдёте 25 сасовых окон - кому слать будемте?
Как вариант при отсутствии хэндла конкретного САСа в командной строке можно выдавать предупреждение и не выполнять команды при наличии нескольких запущенных экземпляров САС. |
|
|
|
|
|
Все правильно. Именно это я и имел в виду. Тот же GE именно так и делает, ну или очень похоже. |
|
|
|
|
>Но vdemidov предложил перенести этот функционал в САС и мне это понравилось
Это глупость. Сам vdemidov ещё раз подумает, и сам кода-нибудо этого дойдёт. Ибо это нужно ТОЛЬКО для лечения родовых травм саса. Именно это и называется рвать гланды через анус. Лечить надо болезнь, а не её побочные симптомы, никто не лечит грипп платочком (а если лечит - это не лечение, а ожидание, что само рассосётся).
>возрастает удобство использования этого функционала
Какого этого? Поднять сас с кучей памяти вместо микропрограмки или скрипта? Я вас умоляю... ничего удобнее и быстрее чем послать команду напрямую сасу из скрипта сделать не получится по определению, ибо именно в этом случае устраняются все ненужные прослойки между источником данных и их получателем.
>класть некий exe для выполнения этих команд?
Зачем обязательно EXE? Плясать надо от печки. Если сейчас данные для саса в скрипте - оттуда и слать. Если данные в другой программе - оттуда и слать. Если надо играться руками - ну сделайте EXE для игр, если будет проще, но по мне так это ненужная прослойка, играться можно и из скрипта. Я вообще не понимаю, почему возникла ХУДШАЯ идея из всех возможных - свой костыль типа DDE через командную строку и мегатяжёлую EXE-ху?
>Давайте определяться
Я предлагаю по крайней мере в этой теме в рамках этой доработки не делать пересылку между сасами, а только локальную обработку. Если она (обработка) будет вместе с обработкой CmdLine в одном обработчике - да за ради бога.
>А какая разница с какой базой работает вызываемая версия САС
Объясняю. Идея пересылки информации между сасами о необходимости создания метки родилась, потому что сас монопольно блокирует SML. То есть другой сас, чтобы записать метку в свою базу меток (из которой он в лучшем случае может только читать), должен попросить ДРУГОГО саса (причём именно того, кто захватил именно его SML на запись, а не любого произвольного), не будет ли любезен многоуважаемый джинн записать ему меточку в SML. Так что ответ "первому попавшемуся" априори неуместен, так как "первый попавшийся" может либо сам быть без доступа на запись в SML, либо вообще может записать метку в ДРУГУЮ базу SML, и в итоге плохо будет обоим сасам. Рассуждать о ситуации, когда база SML недоступна на запись, и ни один из опрошенных сасов тоже не может в неё записать, я даже не хочу, потому что это будет слишком нечестно.
>при отсутствии хэндла конкретного САСа в командной строке
А если хэндл есть, но он стал чужой? Или другой сасзапущен на другом мониторе на другом рабочем столе под другим юзером в другой WinStation?
>не выполнять команды при наличии нескольких запущенных экземпляров САС
Зачем в сасе новые мертворожденные поделки, которые не работают в случае кучи часто изпользуемых вариантов? Их тут и так хватает.
>Тот же GE именно так и делает
Это не повод заниматься такими же глупостями. У GE выбора нет. А у саса есть. |
|
|
|
|
>>Тот же GE именно так и делает
> Это не повод заниматься такими же глупостями. У GE выбора нет. А у саса есть.
У любой программы, которая хочет зарегистрировать под себя какое-то расширение файлов и не открывать новую копию себя при каждом запуске файла с таким расширением, нет выхода кроме как поступать таким образом (Прмеры: Picasa, WinAmp, MPC-HC, GE, Opera, Notepad++ и еще миллион других программ).
Но согласен, что в данной теме это оффтопик. Главное, что я предлагал, так это делать команды совместимые с командной строкой, все остальное это уже детали реализации |
|
|
|
(0011016)
|
|
zarius
|
|
05-04-2013 11:02
|
|
>Поднять сас с кучей памяти вместо микропрограмки или скрипта?
Тоже не нравится этот момент. Понятно что если и делать - делать до инициализации основных объектов САСа, но спасет ли это положение?
>Зачем обязательно EXE?
Затем, что намного проще прописать интеграцию через CmdLine - практически любой пользователь сможет сделать это. Кроме того, не каждое приложение может использовать WM_COPYDATA (закрытость кода и все такое).
>Идея пересылки информации между сасами о необходимости создания метки родилась, потому что сас монопольно блокирует SML.
Не знал об этой идее. Мое мнение - не стоит использовать механизм "пересылки информации между сасами" чтобы решить проблему блокировки SML другим САСом. Вот это точно из разряда "мертворожденные поделки". "Лечить надо болезнь, а не её побочные симптомы" - и я с этим полностью согласен. Если необходимо одновременное использование меток разнымим САСами - необходимо развивать БД меток (SQLite и прочие СУБД)
>А если хэндл есть, но он стал чужой?
Это проблема вызывающего приложения
>Или другой сасзапущен на другом мониторе на другом рабочем столе под другим юзером в другой WinStation?
Данный функционал не предназначен для решения описанных задач. |
|
|
|
(0011019)
|
|
zarius
|
|
05-04-2013 11:19
|
|
В общем я понял что в сторону обработки CmdLine пока не смотрим
Тогда по поводу перевода числовых режимов на рекомендованные vdemidov'ым:
в контексте CmdLine - все здорово, иначе - слишком длинные имена и "лишняя" строковая обработка - надо ли? |
|
|
|
|
> в контексте CmdLine - все здорово, иначе - слишком длинные имена и "лишняя" строковая обработка - надо ли?
по сравнению с затратами на передачу сообщения и данных между процессами это капля в море. Единственный вопрос это достаточно большая сложность кода. Поэтому советую выносить это в отдельный модуль и сразу писать юнит-тесты. |
|
|
|
|
>нет выхода кроме как поступать таким образом
Да ладно )))
Можно зарегистрировать не себя, а микроEXE или скрипт. Соответственно они либо через WM_COPYDATA работают, или через внутренний httpd (из того же консольного скрипта отправлять запросы на http до неприличия просто).
Можно зарегистрировать обработчиком через RunDll32 свою DLL, её же грузить в сасе, а между копиями DLL хоть NamedPipe себе устроить.
Можно ещё настоящий DDE вспомнить.
>делать команды совместимые с командной строкой
Адназначна.
Доступ через WM_COPYDATA - это же по сути легковесный локальный аналог внутреннего httpd, который бы позволил в том числе управлять сасом по сети. И как только в сасе появится внутренний httpd - так сразу же возникнет задача присовокупления обработчика CmdLine + WM_COPYDATA к обработчику внутреннего протокола sas:// (ну или наоборот).
>если и делать - делать до инициализации основных объектов САСа
Если это сделать ДО инициализации - как не профукать такой тонкий момент, что захвативший ранее SML сас сдох, и мы можем смело сами писать в базу меток?
Я потому и предлагаю СОВСЕМ разделить функциональность отправителя и получателя данных, чтобы такой ерунды не возникало.
>намного проще прописать интеграцию через CmdLine
Не совсем. Это проще, если другого способа нет. Тогда действительно придётся писать маааленькую такую EXEху.
Но во-первых она сама не будет ничего блокировать типа SML и будет маленькая и быстрая. Ей надо только уметь транслировать CmdLine в WM_COPYDATA и всё.
Во-вторых, она сама будет искать нужный ей сас, а в сасе этот ненужный код не будет присутствовать.
В-третьих, код пересылки всё равно писать, какая разница где, в сасе или нет?
В-четвёртых, если всё же есть возможность напрямую работать с сасом без неё - она становится не нужна.
>не стоит использовать механизм "пересылки информации между сасами" чтобы решить проблему блокировки SML другим САСом
Именно так. А если поглядеть на параметры, которые сейчас передаются в сас, то там есть параметры:
а) типа zoom - которые очевидно никуда пересылать не надо, если мы их сразу передали куда надо, так как каждый сас зумится сам по себе независимо от собратьев (даже скрыть-показать метки сюда же относится);
б) типа mark для меток - и эти команды надо слать, потому что SML и всё такое.
Так что непересылка первых между сасами решается определением правильного адресата, непересылка вторых между сасами - лечением SML.
>>А если хэндл есть, но он стал чужой?
>Это проблема вызывающего приложения
Нет. Это проблема подхода, потому что невозможно дать гарантию, что между "нашли hwnd саса" и "отправили ему сообщение" окно всё ещё наше. И чем больше времени между этими событиями, чем больше шансов послать сообщение в /dev/null.
>не предназначен для решения описанных задач
Вот именно. Работать будет только в стерильном окружении. Даже если я запускаю 2 саса - уже работать не будет. А 2 саса - это стандартный минимум, один качает, другой из-под delphi запущен. А то бывает и больше. Про терминальный доступ тоже можно сразу забыть. Вот покуда и непонятно, ради чего такая кастрация функциональности, если можно и без неё.
>я понял что в сторону обработки CmdLine пока не смотрим
Нет. Не смотрим в сторону межсасового взаимодействия.
>слишком длинные имена и "лишняя" строковая обработка - надо ли?
Да. Если создать новые строковые константы - больше на памяти потеряется. Максимум что имеет смысл оптимизировать - это а) заранее привести к одному регистру и б) откусывать от строки минимальный отличающийся от остальных кусок с начала строки и сравнивать его. Но я уверен, что там и без оптимизации всё будет летать. |
|
|
|
(0011023)
|
|
zarius
|
|
05-04-2013 14:12
|
|
>Даже если я запускаю 2 саса - уже работать не будет
В моем случае - неважно сколько запущено САСов. Из своего приложения я сам запускаю нужный мне экземпляр САС и получаю его хэндл - далее я работаю только с ним: отправляю команды, меняю размеры, сворачиваю/разворачиваю, делаю поверх всех окон, закрываю и т.д. Но, естественно, это будет работать только в рамках одного рабочего места - в моем случае по другому и не требуется.
>...окно всё ещё наше
хм... а в каком случае хэндл окна может поменяться? ну... понятно что при желании скорее всего можно, но в нашем случае как без специальных ухищрений? |
|
|
|
|
>я сам запускаю нужный мне экземпляр САС
>в моем случае по другому и не требуется
Особенность вашей ситуации в том, что реализуются не все возможные варианты.
И я реально не понимаю, зачем такую специфику превносить в общий код.
>а в каком случае хэндл окна может поменяться?
Попробуйте поискать по дельфёвым исходникам CreateWnd и RecreateWnd. |
|
|
|
|
Полуслучайно натолкнулся - и решил сохранить тут, чтобы не потерялось.
Пример отправки WM_COPYDATA из perl-а:
http://johnbokma.com/mexit/2007/01/17/snarl-with-perl.html |
|
|
|
(0012813)
|
|
frech
|
|
16-09-2013 17:38
|
|
|
запускаю скрипт, но нет результатов. Как все это реализовать через .NET. Так как пищу софт, а там надо по клику переходить к координатам (САС). |
|
|
|
(0012815)
|
|
zarius
|
|
17-09-2013 06:21
|
|
>запускаю скрипт, но нет результатов
Какую версию используете? На текущей сборке проекта все должно работать. На версии v.121010 (последняя стабильная на http://sasgis.org/download/) работать не будет - функционал был добавлен позднее.
>Как все это реализовать через .NET
Поищите реализацию отправки сообщения WM_COPYDATA для .NET - что передавать в сообщении наглядно показано в скрипте. |
|
|
|
(0014733)
|
|
zed
|
|
27-10-2014 17:13
|
|
Основательно переделал обработку событий WM_COPYDATA. Теперь параметры из сообщений и опции командной строки обрабатываюся одинаково. Соответственно, поменялись как сами опции (имена), так и коды возврата.
Сделано, как описано здесь: 0001869:0010996
Доступные параметры:
--move=({lon},{lat})
--zoom={value}
--navigation=({lon},{lat})
--map={GUID}
--show-placemarks={0/1}
Тестируйте. |
|
|
|
(0014734)
|
|
zarius
|
|
28-10-2014 09:40
|
|
|
Отлично! Радует что тема получает продолжение! |
|
|
|
|
|
Только нужно еще поправить генерацию параметров для создаваемого ярлыка, а то они там сейчас в старом формате создаются, если я ничего не путаю. |
|
|
|
(0014736)
|
|
zed
|
|
28-10-2014 11:08
|
|
|
|
|
|
|
В меню Файл есть кнопочка создания ярлыка на текущую позицию. |
|
|
|
(0014738)
|
|
zed
|
|
28-10-2014 11:44
|
|
> В меню Файл есть кнопочка создания ярлыка на текущую позицию.
Ага, точно. Исправил.
Добавлена опция для вставки метки:
--insert-placemark="{name}";({lon},{lat});"{desc}"
и добавил возможность импортировать файлы (всех поддерживаемых форматов), правда при импорте через командную строку получается облом, т.к. база меток оказывается ещё неинициализирована на момент вставки. Но через сообщения должно работать.
Базу меток надо дорабатывать, чтобы у нас всегда была in-memory база, которую можно юзать сразу же при запуске приложения. Она должна быть временной, но с возможностью переноса меток из этой БД в основную. Об этом был разговор ещё в 0000033 и импорт меток через командную строку, видимо, будет ещё ждать своего часа.
zarius
Радует, что вы ещё с нами. Займитесь тестирование фичи? Я обработку сообщений вообще не тестировал, поэтому очень желательно всё проверить. |
|
|
|
|
>Базу меток надо дорабатывать, чтобы у нас всегда была in-memory база, которую можно юзать сразу же при запуске приложения. Она должна быть временной, но с возможностью переноса меток из этой БД в основную.
Ага. Для этого кстати можно существующую SML порезать и будет in-memory база. Нужно только выкинуть все сохранения и свой генератор id-шников сделать хотя бы на базе простого интового счетчика. |
|
|
|
(0014740)
|
|
zed
|
|
28-10-2014 11:58
|
|
Да, там много чего нужно сделать. Нужно научиться работать сразу с несколькими БД и переносить метки между ними.
На это дело вообще нужно открыть отдельный тикет и связать с 0000033 как блокирующий. |
|
|
|
(0014741)
|
|
zarius
|
|
28-10-2014 12:54
|
|
>Займитесь тестирование фичи?
Постараюсь седня-завтра собрать проект и потестить
>Нужно научиться работать сразу с несколькими БД и переносить метки между ними
Можно поподробнее? |
|
|
|
(0014742)
|
|
zed
|
|
28-10-2014 13:03
|
|
> Можно поподробнее?
А что тут не понятно? Сейчас есть одна база меток, а надо чтобы можно было подключить сразу несколько и разных типов. Я это замечание сделал к тому, что нужно дорабатывать IMarkSystem, иначе импорт меток из командной строки работать не будет, несмотря на то, что такая обработка уже предусмотрена и должна работать через WM_COPYDATA. |
|
|
|
|
>Да, там много чего нужно сделать. Нужно научиться работать сразу с несколькими БД и переносить метки между ними.
Так вроде никаких проблем. Оно прекрасно будет работать. У метки есть поле с DbId. Так что оно опознает чужие метки. Нужно только в ГУЙ добавить отображение временной базы как отдельной категории в базе меток. |
|
|
|
(0014744)
|
|
zarius
|
|
28-10-2014 13:47
|
|
>А что тут не понятно? Сейчас есть одна база меток, а надо чтобы можно было подключить сразу несколько и разных типов
Не понятно, что имеется под "БД разных типов" и как их планируется подключать. Сейчас, насколько я знаю, имеется только один формат БД меток - это SML (проект SACS, как я понимаю, здесь не рассматриваем). Или имеется ввиду, что в качестве БД меток подключать импортируемые файлы kml и т.д.? |
|
|
|
(0014745)
|
|
zed
|
28-10-2014 14:40
(edited on: 28-10-2014 14:52) |
|
> что имеется под "БД разных типов" и как их планируется подключать
Ну вот как тайлы хранятся в разных типах кэша, так же и метки нужно сделать. И пока что не суть важно, как конкретно другие базы меток будут их хранить. Важно, что нету механизма подключения/переключения/взаимодействия разных БД, а он нужен в первую очередь. Для кэша тайлов, я помнится, очень легко и непринуждённо сделал и подключил RAM-кэш, потому что механизм там был заложен уже давно. В метках же такого нету, и несмотря на то, что сделать RAM-кэш для меток может быть очень просто, подключить его может оказаться на порядок сложнее. Сейчас вся логика завязана на то, что есть одна-единственная "рабочая" база меток и вот эту логику нужно изменять, чтобы одновременно можно было сделать рабочими несколько разных баз. Даже SML базы можно подключать из разных директорий в различных режимах чтения/записи.
|
|
|
|
(0014746)
|
|
zarius
|
|
28-10-2014 15:04
|
|
|
Теперь все понятно. И, хотя, именно это я надеялся услышать - все же были сомнения, что я понял что то не так. Думаю, что это именно то, чего так не хватало в подсистеме меток - "механизма подключения/переключения/взаимодействия разных БД". |
|
|
|
|
|
Еще было бы круто, если бы при запуске второго экземпляра программы с парметрами, но без указания параметра --new-instance, что бы все параметры передавались уже запущенному экземпляру через WM_COPYDATA и новый экземпляр сразу закрывался. Тогда можно добавлять ассоциации с любыми поддерживаемыми расширениями и не нужны никакие дополнительные утилиты для управления из командной строки. |
|
|
|
(0014748)
|
|
zed
|
|
29-10-2014 08:21
|
|
|
Тут возникает много вопросов и это нужно обсуждать отдельно. |
|
|
|
|
|
А в чем вопросы? ИМХО единственная проблема, это поиск окна, которому слать сообщение WM_COPYDATA и что делать если подходящих окон несколько. |
|
|
|
(0014760)
|
|
zed
|
|
29-10-2014 08:46
|
|
|
Проблема не единственная. Обработку параметров как минимум нужно переносить на более ранний этап. |
|
|
|
|
|
Не всю, а только дополнительные проверки. То есть до создания главной формы нам нужно только проверить наличие параметра --new-instance и если его нет, то попытаться найти другой экзепляр, которому отослать весь пакет параметров без детального разбора. |
|
|
|
(0014762)
|
|
zarius
|
|
29-10-2014 08:52
|
|
>что бы все параметры передавались уже запущенному экземпляру через WM_COPYDATA
Эта тема уже поднималась, но была зарублена vasketsov'ым. Насколько помню, из-за не эффективности такого подхода. Возможно будет проще в каталог с SASом положить исполняемый файл (к примеру, тот же скопмилированный скрипт), через которого и передавать сообщения в уже запущенный SAS. Но опять встает уже поднимавшийся ранее вопрос - как определить в какой из экземпляров SASа передавать эти сообщения, если этих экземпляров будет несколько. В общем - есть над чем подумать. |
|
|
|
(0014764)
|
|
zed
|
|
29-10-2014 08:53
|
|
Ну вот и говорю - куча нюансов, которые решать нужно отдельно.
А в этом тикете я жду фидбека от zarius и закрываю. |
|
|
|
(0014767)
|
|
zarius
|
|
29-10-2014 09:02
|
|
>определить в какой из экземпляров SASа передавать эти сообщения, если этих экземпляров будет несколько
Как вариант - назначать при необходимости некий ИД запускаемому SAS. К примеру, --ID="FIRST". Тогда при посылке сообщений мы так же указываем этот ИД. Без указания ИД сообщение уходит первому попавшемуся экземпляру SAS. |
|
|
|
|
|
На первое время варниант "уходит первому попавшемуся экземпляру" более чем достаточен. А вот уже дальше можно придумывать. |
|
|
|
(0014770)
|
|
zed
|
|
29-10-2014 09:29
|
|
|
На первое время, достаточно открыть новый тикет и вносить все предложения там. |
|
|
|
(0014773)
|
|
zarius
|
|
29-10-2014 11:29
|
|
>А в этом тикете я жду фидбека от zarius
Проверил работу как при запуске приложения, так и при пересылке сообщений:
все команды работают, за исключением "--insert-placemark" - в режиме запуска ничего не происходит (метку не добавляет), в режиме сообщений выдает ошибку
http://oi62.tinypic.com/28vskes.jpg
сообщение посылал: --insert-placemark="p1";(49.684498,58.594136);"МЕТКА1" |
|
|
|
|
|
Ну да. Все правильно. Zed создает новую категорию TEMP, но не сохраняет ее в базе перед сохранением метки. |
|
|
|
(0014778)
|
|
zarius
|
|
29-10-2014 12:05
|
|
>Zed создает новую категорию TEMP, но не сохраняет ее в базе перед сохранением метки
Подтверждаю - после создания категории "TEMP" - метка появляется в режиме сообщений
В режиме запуска как и раньше - метка не появляется даже при наличии категории "TEMP" |
|
|
|
|
>В режиме запуска как и раньше - метка не появляется даже при наличии категории "TEMP"
Это как раз ожидаемо. Zed сразу сказал, что "правда при импорте через командную строку получается облом, т.к. база меток оказывается ещё неинициализирована на момент вставки." |
|
|
|
(0014780)
|
|
zarius
|
|
29-10-2014 12:13
|
|
>правда при импорте через командную строку получается облом, т.к. база меток оказывается ещё неинициализирована на момент вставки
в принципе понятно почему метка не появляется в режиме запуска - можно оно и не надо в этом режиме? |
|
|
|
(0014781)
|
|
zed
|
|
29-10-2014 12:14
|
|
vdemidov
Так, значит нужно куда-то впереть UpdateCategory(nil, NewCat) и всё?
zarius
Проверьте ещё импорт файлов меток и jpeg с exif. Там эта обработка тоже прикручена:
SASPlanet.exe file1 file2 ... fileN |
|
|
|
|
|
Просто если ты делаешь UpdateMark то ожидается что метки уже готовы для импорта. Что они относятся к категориям из обновляемой базы и тд. Если ты импортируешь сторонние метки, то тогда нужно вызывать ImportItemsTree. Хотя мне все еще не нравится вся эта лабуда. Просто не могу придумать как сделать и удобно и эффективно. |
|
|
|
|
|
В тупую UpdateCategory(nil, NewCat) так как он втупую сделает еще одну категорию с таким именем. Нужно проверять наличие категории перед созданием. Мы ж вроде бы это обсуждали, когда ты импорт sml допиливал. |
|
|
|
(0014791)
|
|
zed
|
|
29-10-2014 13:04
|
|
|
|
|
|
|
Должно. Единственная особенность, что даже если метка/метки не будут импортированы из-за ошибки, категория TEMP создастся в любом случае. |
|
|
|
(0014794)
|
|
zarius
|
|
29-10-2014 14:08
|
|
>Проверьте ещё импорт файлов меток
Не совсем понял что проверять - проверил на свежесобранной SAS - kml, kmz и sml в режиме запуска не импортируются |
|
|
|
(0014795)
|
|
zed
|
|
29-10-2014 14:49
|
|
> kml, kmz и sml в режиме запуска не импортируются
А через сообщения должно работать. Я же писал, что работа с метка через командную строку пока недоступна. |
|
|
|
(0014800)
|
|
zarius
|
|
30-10-2014 06:18
|
|
>Я же писал, что работа с метка через командную строку пока недоступна.
Это я как раз понял... смутило "SASPlanet.exe file1 file2 ... fileN" |
|
|
|
(0014839)
|
|
zed
|
|
01-11-2014 10:54
|
|
|
Параметр --navigation=({lon},{lat}) переименован в --navigate=({lon},{lat}) |
|
послать сообщение SAS.au3 (2,243) 29-03-2013 06:35