Форум » [x]Harbour » Как "заморозить" выполнение программы ? » Ответить

Как "заморозить" выполнение программы ?

Andrey: Всем привет. Подскажите как можно остановить (заморозить) выполнение программы до выполнения определенного события в другой программе ? Т.е. я из своей программы на хХарборе (терминалка) запускаю допустим программу "Скачивания из инета" на МиниГуи. Терминалку на хХарборе нужно "заморозить" до конца скачивания ! Иначе ЮЗВЕР будет тыкать мышкой раньше времени.... После того как скачался файл нужно вернуться обратно в терминалку на хХарборе ! Можно конечно сделать "семафорный файл" после получения файла из инета, а в хХарборе проверять каждую минуту есть такой файл или нет. Но это можно было делать и на Клипере (проверку файла). А что нам может предложить хХарбор ?

Ответов - 66, стр: 1 2 3 4 All

Dima: Andrey пишет: А то мусорница начинается, потом форум читать трудно будет. Не мусори

Andrey: SergKis пишет: сохранил экран\сделал новый с крупным письмом типа "Ж Д И Т Е ...", потом все воссстановил. Все время так делаю. Пользователь не такой тупой, все понимает, пусть и не с первого раза. Сделал для юзера "Ж Д И Т Е ..." cRunExe := M->SetPath + "MiniGui-module.exe " + cParam EXECANDWAIT(cRunExe) После старта модуля на МиниГуи терминалка висит и сообщение Программа (не отвечает) ! Как это убрать ? Может можно как то повесить показ таймера через каждую секунду или две ? Пробовал сделать как в Пост N: 3833 http://clipper.borda.ru/?1-4-0-00000954-000-0-0-1392306838 Все равно прога висит... Юзер по не знанию может прогу на терминалке крестиком закрыть...

SergKis: Andrey ты запускаешь execandwait, т.е. терминалка должна висеть до завершения минигуи. Определись чего хочешь ? Хочешь, что то делать, делай с idle, пример есть в TEST каталоге, посканируй.


SergKis: Andrey пишет Юзер по не знанию может прогу на терминалке крестиком закрыть... У себя крестик закрываю наглухо (что бы не было желания нажимать). Выход только по меню или кнопкап, т.е. где разрешено.

Andrey: Возник вопрос другой. Как можно из своей программы (1) запустить заново себя (2) с ожиданием, пока не выгрузиться из памяти (1) сама прога ? Т.е. по [pre2]ShellExecute( , 'open', Application.ExeName, cParam, , 2 )[/pre2] прога слишком быстро загружает вторую копию программы. Нужно с ожиданием, пока не выгрузится первая. Если в начале проги стоит команда [pre2] _HMG_MESSAGE[4] := "Попытка запуска второй копии программы:" + CRLF + ; App.ExeName + CRLF + ; "Отказано в запуске." + CRLF + _HMG_MESSAGE[4] SET MULTIPLE OFF WARNING [/pre2] То при запуске второй проги срабатывает эта команда. Из-за этого и нужен запуск с ожиданием. Как это можно сделать ?

SergKis: Andrey wApi_Sleep(1000) или лови handle окна и текст первого запуска, пока находится, жди, нет его, работай дальше

Dima: ISEXERUNNING ?

Andrey: Dima пишет: ISEXERUNNING ? Не совсем... SergKis пишет: или лови handle окна и текст первого запуска, пока находится, жди, нет его, работай дальше Не совсем понятно как делать. Вот примерно такой у меня код: [pre2]#define PROGRAM 'Моя прога' .... Function Main .... hWnd := FindWindow( PROGRAM ) // здесь же 2 хендла будет. Как перебрать ? // проверка и ожидание // Проверка на запуск второй копии программы OnlyOneInstance( PROGRAM ) .....[/pre2] Хотя хендл проги (1) можно передать в вызов копии проги (2). Это я понимаю как сделать. А не передавая хендл окна можно сделать ожидание ?

SergKis: Andrey пишет Не совсем понятно как делать. Ты только недавно спрашивал про OpenOffis Excel и тебе было предложено EnumWindow() и т.д. Ловишь во второй копии с cParam запуском ShellExecute() Если в первом запуске будешь создавать mutex, можешь ловить его наличие, эту ф-ю то же видел[pre2] FUNCTION IsExe2Run( cDop ) // Проверка второго запуска программы + (режим или ini) LOCAL i, cMut, hMut, lMut LOCAL cExe := hb_ProgName() LOCAL lRet := .T. STATIC s_hMutex := 0 DEFAULT cDop := "" IF ISLOGICAL(cDop) IF ! empty(s_hMutex) wapi_ReleaseMutex( s_hMutex ) s_hMutex := 0 ENDIF RETURN lRet ENDIF IF ! empty(cDop) .and. ( i := RAt("\", cDop) ) > 0 cDop := subs(cDop, i+1) ENDIF cMut := upper(cExe + cDop) AEval({".","\",":","/"," "}, {|cs| cMut := StrTran(cMut, cs, "_") }) hMut := wapi_CreateMutex( NIL, NIL, cMut ) lMut := ( ! Empty( hMut ) .and. wapi_GetLastError() == 0 ) IF lMut s_hMutex := hMut lRet := .F. ENDIF RETURN lRet // .T. - повторный запуск (mutex уже есть) [/pre2]

Andrey: SergKis пишет: Ты только недавно спрашивал про OpenOffis Excel и тебе было предложено EnumWindow() и т.д. Да я этот вариант помню. Просто думал ещё по другому можно ? И EnumWindow() даёт оба хендла окна. А как узнать хендл окна второй проги ? Т.е. без передачи через cParam узнать нельзя ? Если нельзя, то понятно как делать.

SergKis: Andrey пишет Ф-я myGetWindowHandles( cText, cClass, lLogOut ) из темы http://clipper.borda.ru/?1-4-0-00000214-000-20-0-1592817166 находит по части текста title + класс окна, в hmg это HMG_<имя main окна>Да я этот вариант помню. Ты запусти ф-ю с получением лога и все увидишь и текст и класс, вот их и контролируй или используй mutex ф-я выше. В первой создаешь, во второй - проверяешь, если есть, то первая еще работает, нет - закончила работу, вторая перестает ждать, начинает работать. Где тут параметры cParam ? Хотя имя mutex можешь передавать, если имя "плавает"

Haz: Зачем мутить с окнами? 1 Программа при старте получает хендл своего основного процесса 2 Запускает через processrun свою копию ( причём путь запуска можно брать из своего процесса) и передаёт копии хендл. 3 перед инициализации ей главного окна - ожидание завершения предыдущей копии по хендлу. Мжно и не ждать, а терминировать принудительно. Можно и без передачи хендл, тогда запускаемый процесс ищет предыдущую копию и прибивает её. Всё через wmi достаточно просто реализуемо.

SergKis: Haz пишет Зачем мутить с окнами? Особенно, когда их нет. Консоль, wvt без окна. Лучше для управления процессами использовать mutex, по мне Win32 API в Windows имеет две реализации мьютексов — собственно мьютексы, имеющие имена и доступные для использования между разными процессами, и критические секции, которые могут использоваться только в пределах одного процесса разными потоками[

Andrey: Haz пишет: Всё через wmi достаточно просто реализуемо. А примерный код можешь показать ?

Dima: Andrey пишет: А примерный код можешь показать ? Ожидаемый вопрос

Haz: SergKis пишет: Особенно, когда их нет. Консоль, wvt без окна. Лучше для управления процессами использовать mutex, по мне Разве мутексы не есть семафоры в потоках? В рамках одного процесса можно рулить потоками , но как мутексами рулить в разных процессах ?? это уже из области задач операционки Или я не о том ?

Haz: Andrey пишет: А примерный код можешь показать ? работа с WMI достаточно хорошо представлена в примерах MINIGUI (поиск по всем *.PRG содержимого WMI ) один из моих древних примеров это tsb_Filter. для понимания рекомендую скачать WMIExplorer - бесплатную и простую версию. Работа через SQL запросы к WMI сервису. Возможностей много, в конкретной задаче интересует запрос к Win32_Process Вот так я убиваю зависшие процессы Excel hWnd:=oExcel:hWnd ... oWmi := WmiService() cSql := "SELECT * FROM Win32_Process WHERE Handle = " + NTOC(GetWindowPID(hWnd)) FOR EACH oItem IN oWmi:ExecQuery( cSql ) oItem:Terminate() NEXT

SergKis: Haz пишет Разве мутексы не есть семафоры в потоках? Мьютекс Материал из Национальной библиотеки им. Н. Э. Баумана Последнее изменение этой страницы: 11:24, 29 октября 2016. Мью́текс (англ. mutex, от англ. mutual exclusion — «взаимное исключение») — является аналогом одноместного семафора, в программировании необходим для сопоставления синхронно выполняющихся потоков.[1]. Мью́текс представляет собой концепцию программирования, которая используется для решения вопросов многопоточности. Мьютекс отличается от семафора тем, что допускает только один поток в контролируемом участке, заставляя другие потоки, которые пытаются получить доступ к этому разделу ждать, пока первый поток не вышел из этого раздела. Принимает два значенения: открыт - поток может войти в свою критическую секцию; закрыт - поток не может войти в критическую секцию. Задача мьютекса — защита объекта от доступа к нему других потоков, отличных от того, который завладел мьютексом. В каждый конкретный момент только один поток может владеть объектом, защищённым мьютексом. Если другому потоку будет нужен доступ к переменной, защищённой мьютексом, то этот поток засыпает до тех пор, пока мьютекс не будет освобождён. А.КресинИтак, для предотвращения одновременого обращения разных потоков к одному и тому же ресурсу делаем следующее: 1) создаем предварительно mutex: pMtx := hb_mutexCreate() 2) в тех местах программы, где происходит обращение к защищаемым ресурсам, оборачиваем соответствующий код блокировкой/разблокировкой mutex'а, т.е. ставим перед перед ним hb_mutexLock( pMtx ) и после него hb_mutexUnLock( pMtx ) - точно так же, как мы блокируем/разблокируем запись расшаренной базы данных при записи в нее. Не забывайте, что, в отличие от rlock(), hb_mutexLock() приостанавливает дальнейшее выполнение потока, если mutex уже чем-то заблокирован - при невнимательности можно получить deadlock - ситуацию, когда несколько потоков взаимно заблокировали выполнение друг друга. собственно мьютексы, имеющие имена и доступные для использования между разными процессами Это использовано в функции выше. Т.е. создаем\убираем mutex в разных приложениях и можем управлять тем или иным алгоритмом.процессом

Haz: SergKis пишет: Это использовано в функции выше. Т.е. создаем\убираем mutex в разных приложениях и можем управлять тем или иным алгоритмом.процессом Сергей, в многопоточке это понятно. Я не пойму как это сделать в разных приложениях, у каждого свои потоки в рамках основного процесса. Ты говоришь что можно мютексами общаться между разными запущенными программами.? Не пробовал однако

SergKis: Haz пишет Ты говоришь что можно мютексами общаться между разными запущенными программами.? Mutex это переменная (имя), которую можно создавать, удалять и даже этого уже достаточно, что бы приостанавливать одну прогу, давать работать другой, проверять наличие проги в памяти и если нет, то запускать. К примеру mutex в LetoDbf сервере позволяет сделать простой менеджер слежения, есть в памяти он или нет, т.е. простенькое меню Start Server, Stop Server, Exit и соответсвенно в таком меню делать пункты disable\enable от наличия\отсутсвия сервера в памяти, а проверка по timer наличия mutex позволит автоматически запускать его при отсутствии в памяти. При обеспечении сервером (каждого своим) нескольких клиентов (в разных каталогах установка) такой менеджер может по mutex обеспечить устойчивую работу (что бы всегда был запущен) каждый сервер для своего клиента (под клиентом тут надо понимать организацию). Сервис для сервера не используется у нас.



полная версия страницы