AntonariyЕсть вполне легальный способ поюзать многопоточность — ActiveX exe.
Попробовал.
1.Создал ExeServer (ActiveX EXE), в классе написал
Скомпилировал.

2. Создал ExeClient, в рефренсах добавил ссылку на ExeServer.exe
Создал кнопку
Запустил, нажал на кнопку, получил Automation error
Проект прилагается. Гнилая технология? Или что не так сделал?
============================================
Зачем все нужно.
Хочу прикрутить GhostScript к проге.
Есть способ запустить GhostScript под VB через прямой доступ к dll.
tp://95.129.137.164/rented/znamensk/CTAN/support/ghostscript/contrib/gsapi_vb.zip
Все просто и чудесно работает, но CallGS(astrArgs) грузит прогу пока не завершится,
т.е. ее надо запускать в отдельном потоке.
Если конвертируемый файл большой, то это довольно долгая процедура.
Не уверен что мне такой подарок нужен, уже намудохался зимой с интернет-функциями.

Есть кстати оффициальный комментарий:
The Ghostscript Interpreter Application Programming Interface (API)
5 Multiple threads
The Ghostscript library should have been compiled with a thread safe run time library. Synchronisation of threads is entirely up to the caller. The exported gsapi_*() functions must be called from one thread only.

ActiveX Dll уже попробовал, толку никакого.
Якобы ActiveX EXE является лечением, хочу попробовать, типа она запускает действо в отдельном внешнем потоке.

Есть конечно старый детский проверенный способ:
1) сделать свой ghostscript.exe (на VB)
через Shell запускать и ждать (ShellExecute)
Но как то не очень хочется, имея прямой VB доступ. Да и параметров там кучу(в общем случае) передавать надо, их разгребать через Command умучаешься.

Shocker.ProОткрыл твой ExeClient.vbp, нажал кнопку, получил результат. ExeServer.exe при этом использовался твой, regsvr не делал, перекомпиляцию не делал
regsvr кстати кажется и не получится.
А я вот скачал чужой проект от балды, и у меня та же проблема и с ним (Automation error).

>Скорее всего проблема в последовательности компиляций
Никакого толку.

Не знаю, стоит ли с этим вообще пытаться вязаться.
Ну, допустим полечу. А человек установит прогу и у него проблема воспроизведется, оно надо?

Пока занимаюсь изготовлением "обычного exe" вместо серверного.
В смысле запуск через Shell с параметрами.

>Если не хочеш этой мороки, изпользуй Late Binding.
Позднее связывание?
Set что-то =CreateObject( ???
Не врубаюсь, а как оно полечит "выполнение процедуры в другом потоке"

Раннее, позднее, здесь думаю не суть важно.
basicvДа, странно, сейчас скачиваю проект заного, запускаю ExeClient.exe и всё отрабатывает нормально, хотя раньше вылетала ошибка.
Я вот тоже на соседнем компе запустил:
1. ExeClient.exe ,пишет
bla-bla-bla Can't create ActiveX object
2. Запускаю ExeServer.exe, ну там "часики песочные" мигнули
3. Запускаю снова ExeClient.exe , заработал гад

А на рабочем компе, где все это сотворил нивкакую.

Вирусописание все это короче, коэф. надежности =0,0%.

Сделал вместо ExeServer.exe короче ExeNormal.exe
и хочу делать ShellAndContinue ExeNormal.exe <строка параметров>, vbтакой-тоfocus

В конце концов GhostScript все равно результатов через ф-цию не возвращает и надо после отработки проверять наличие выходного файла. А <строка параметров> не такая уж страшная получилась, ибо знаю ж какую конкретную процедуру буду делать, весь парсинг уже написал, вроде усе путем.

Ну, единственный минус, что ShellAndContinue в той реализации как я использую показывает "липовую" загрузку процессора 100%(ну или 50% на Dual). Да и бог с ним, GS сам кажется этим тоже страдает, и "липовым" ли образом? ой-ли...

Дмитрий77Не уверен что мне такой подарок нужен, уже намудохался зимой с интернет-функциями.

Есть кстати оффициальный комментарий:
The Ghostscript Interpreter Application Programming Interface (API)
5 Multiple threads
The Ghostscript library should have been compiled with a thread safe run time library. Synchronisation of threads is entirely up to the caller. The exported gsapi_*() functions must be called from one thread only.
А с другой стороны стандартные GDI-преобразования типа
в этом отношении такие же мерзкопакостные,
так что думается уже мне, что я ерундой страдаю, можно лепить GS в основной код как есть.
Преобразование 3-х страниц хоть через GDI, хоть через GS относительно незаметно.
А если 400 страниц, то юзер "сам дурак", потому как это противоречит логике программы и здравому смыслу.
(400 страниц факса!!!) Сиди-жди...дождешься.
В случае с интернет функциями хуже: там можно и не дождаться, но там я извернулся через Inet контрол...

ExeServer регистрируется в реестре не через resvr32, а путем нажатия на ExeServer.exe (однократного запуска).
HKEY_CLASSES_ROOT\CLSID\{2E77760A-2F22-436C-8A9C-D2F7A8CE60C8}
HKEY_CLASSES_ROOT\CLSID\{2E77760A-2F22-436C-8A9C-D2F7A8CE60C8}\LocalServer32
На моем рабочем компе значение LocalServer32 получилось
C:\Documents and Settings\Дима\Рабочий стол\test\WIATest\gsapi_vb\ExeServer\ExeServer.exe
И естественно уже не меняется скоко на него не жми в любых директориях.
Проблема решилась заменой (ручками) параметра на
C:\Docume~1\Дима\Рабочи~1\test\WIATest\gsapi_vb\ExeSer~1\ExeServer.exe

Но, вот думаю. С одной стороны попробовать надо. И пожалуй запихнуть в этот сервер и GS и GDI в куче.
Ну понятно, инсталлер тупо делает ExeServer.exe по месту установки.
И куда его? В system (условно 32)? Юзеру никто не запрещает установить прогу по пути типа моего.
А как uninstall делать? Лезть лопатой в реестр?

С одной стороны, меня и ShellExecute (и даже просто Shell) устроит.
А с другой стороны, сервер должен возвращать результат в прогу (есть такие моменты), Shell этого не сделает.

Стоит ли все же с этим "вирусом" вязаться?

Игорь, Ваш пример не понял, дасайте по простому.

Игорь Горбонос> Автор: Дмитрий77
> ExeServer регистрируется в реестре не через resvr32, а путем нажатия на ExeServer.exe (однократного запуска).
Exe server регистрируется запуском сервера с ключем /RegServer .

Меня бы больше всего устроило, чтоб этот гад (который сервер) вообще не регестрировался в реестре, ни с ключом (как вы сказали) ни нажатием на него просто (как я обнаружил). Причем ни нарочно , ни случайно , почувствуйте разницу:
нарочно - инсталлятор бухнул в System и зарегистрировал
случайно - кинул юзер на его на рабочий стол и нажал - и кривой путь с пробелами и национальным уклоном, типа как я привел.

Игорь ГорбоносТакой сервер не обязательно регистрировать, если exe-файл лежит в одной папке с вызывающей программой.
В-ооооот...Ето меня бы устроило.
Как этого добиться?

Короче по вашему примеру в клиенте написал:

Ну а ссылку в референсах убрал вообще, реестр зачистил от предыдущих экспериментов.


Пишет гад: 429 Can't create ActiveX Object, в какие папки не сунь обоих: хоть Рабочие столы, хоть в C:\111
Как этот сервер стартануть минуя реестр?

Antonariy,

чего то у меня с манифестами не фурычит. Как только создаешь клиентский манифест, client.exe начинает ругаться, мол прога неправильно настроена. (в приложении)

Там вообще про dll-сервер говорится, а у меня exe-сервер. Хотя какая разница, ругается Client а он по любому exe.

Ваш первый пример я взглянул, но возникли сомнения, что такой способ создания объекта сохранит свое предназначение: запуск функции сервера в своем потоке.

И потом, даже если удастся полечить манифесты, их в ресурсы то пихать можно? Клиентский допустим да. А серверный должен валяться в папке на обозрении?

М.б. все же плюнуть, бухать в System(в wow или 32 пусть инсталлятор решает, он же и регистрирует, обычно не ошибается) и там регистрировать? Без администратора моя прога все одно работать не будет, по крайне мере устанавливаться.

Я уже использую маленькую X.dll (не exe), бухаю в по умолчанию /Program Files/proga и регистрирую.
Но я вот счас задумался: а если user сменит default install path на падпапку рабочего стола, ведь сглючит по эффекту "кривого пути" небось и она, гадина. Просто я ее сразу в нормальном пути делал, это я сейчас так удачно нарвался.
Видимо не нашлось еще такого user-а кот. проги в рабочий стол устанавливает.
Но зато нашелся разработчик Дима, кот. папку test с VB-"хламом" хранит аккурат именно там.

Ну, конечно пора уже собсно сотворить этот большой X-exe (с нехилым кодом) и посмотреть как он вооще себя ведет, а не играться с классом из одного MsgBox-а.

Кстати сразу задал уж себе вопрос. А если ф-ция class-а будет вызывать другое приложение с интерфейсным окном из под себя, не будет ли это окно на Vista/Win7 и в терминальных сессиях лезть под SYSTEM (окно-невидимка)?
Удаленный рабочий стол, проблема с правильным функционированием нек. приложений.

Хотя бог с ним, это-ж функция, она вернет результат в основное User-приложение, оно пусть и запускает "окна".

AntonariyЕсть вполне легальный способ поюзать многопоточность — ActiveX exe.
Вы меня, сдается, жестоко обманули в главном.
Или мы просто друг друга не поняли. Или я не понял.

Значит, смотрите.
Есть какая-либо ф-ция, которая "весит" программу.

Один пример, это Internet API, висим пока не сконнектимся с сервером, не закачаем то что нужно. Много с ними бодался в начале года, если помните.

Другой пример, с чем я сейчас занимаюсь.
1) Всевозможные GDI/GDI+ преобразования
2) Функции вызываемые из GhostScript

Выше об этом немного писал.

На отработку этих ф-ций может уйти несколько минут. Например нажали на кнопку и скомандовали проконвертировать цветной PDF в черно-белый TIFF.
После того как мы это сделали, ни один элемент формы из которой сделали, не будет доступен пока этот тифф в 400 страниц не сконвертируется.

Я понял вашу фразу следующим образом: если я запихну ф-цию конвертации в Class, который в ActiveX EXE, то при нажатии на кнопку "конвертировать" ActiveX EXE независимо (в отдельном потоке) займется своими делами, а я могу дальше нажимать на форме другие кнопки , а когда ф-ция отработает, то результат вернется назад в основное приложение.

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

Так как ? Где истина? Потому что если я Вас понял неправильно и указанная задача не решается, то весь этот базар с ActiveX EXE суть пустая трата времени. Тогда проще сделать X-DLL,
а еще проще весь код (модули) запихнуть в основное приложение, по крайне мере это исключит все бяки с регистрацией ActiveX по ненадежным например путям.

Еще вопрос такой.
А можно на VB сделать DLL, чтобы объявлять ф-ции через Declare без глючных ActiveX классов c их регистрациями и неработающими манифестами?
Типа положил dll в папку с exe и все путем.

Дмитрий77Я уже использую маленькую X.dll (не exe), бухаю в по умолчанию /Program Files/proga и регистрирую.
Но я вот счас задумался: а если user сменит default install path на падпапку рабочего стола, ведь сглючит по эффекту "кривого пути" небось и она, гадина. Просто я ее сразу в нормальном пути делал, это я сейчас так удачно нарвался.
Видимо не нашлось еще такого user-а кот. проги в рабочий стол устанавливает.
Но зато нашелся разработчик Дима, кот. папку test с VB-"хламом" хранит аккурат именно там.
ActiveX.dll этот тест прошла.
Хоть за это можно не переживать и не сорить в System.

Игорь ГорбоносВот и вся фишка :)
Чет я не врубаюсь в фишку.
При инициализации класса у вас создается экземпляр формы с взведенным таймером и таймер делает PrintDoWord.

А как мне
1) передать параметры серверу
2) вернуть результат

Result= Function(parameter1, parameter2)

Понимаете, если мне не нужен результат в клиенте, я могу просто сделать Shell (exe) и никаких висяков...
и никаких серверов не надо.
Или могу попросить сервера писать Result в файл, а клиентом тупо ждать этого файла (например по таймеру в клиенте или через DoEvents).
Но такие методы еще хороши при взаимодействии проги C++ и проги VB... а так сами понимаете тон дурноват.

Я не могу понять зачем мне тогда именно глючное образование "EXE-сервер".

Ну, хорошо, получился у меня этот фокус, with Events правда пока не разбирался, но идею воспроизвел, пока идет конвертация могу щелкать элементы на тестовой форме.
Но мне это шибко не нравится. Получается я этот класс и убить то не могу а постоянно должен держать на взводе.
Ну, допустим я могу его создать, нажав на кнопку "конвертировать", сделать кнопку desabled (чтоб исключить возможность параллельно делать другое задание), дождаться события (OK либо описание ошибки, кот. вернет function), убить класс =nothing и сделать опять кнопку доступной.
Хорошо,
1) А X-dll вместо X-exe я так использовать могу? Я объяснил выше, почему мне X-exe не нравится. Оно не умеет по кривым путям регистрироваться, и можно нарваться, а в System все валить нет никакого поверьте желания, надо класть все в Install Path (и никто не запрещает формально быть ему кривым).
2) AntonariyНа закуску, клиент и сервер можно реализовать в одном exe и не парить себе голову совместимостью.
Как это сделать? Если таймер бухать на ту же форму основного приложения, то висяк по любому обеспечен.

AntonariyВы выдвигаете два взаимоисключающих требования: вы готовы делать что-то еще, пока ActiveX exe занимается своей работой, и тут же вам нужен результат немедленно - Result= Function().
Одновременно не бывает. Если результат нужен немедленно, то придется ждать, function может вернуть лишь результат
успешности запуска задания..
Понимаешь, в принципе я готов ждать, и это оптимальный вариант лишенный всех этих заморочек.
Но есть проблема. Пока идет процесс, если юзер тыкается в форму, то она в неадеквате.
Всякие там часики, пишет "не отвечает", если очень стараться, то можно нарваться на мерзкое окно Switch to/Retry с желтыми прямоугольничками.
Хорошо бы чтоб на это время форма была просто типа Disabled, а еще лучше, если б выводилось маленькое окошко с сообщением типа "Please wait...This can take some time...". Я такое окошко делать пробовал, и оно даже изначально неплохо выглядит, если ему сделать FormОкошко.refresh (до запуска процедуры которая "весит"), но если в это окошко тыкаться, то оно само в неадеквате.
Вот это как то можно облагородить?

Еще есть вариант сделать процедуру обычным EXE и вызывать как Shell( EXE with parameters ,vb...) (без всяких ожиданий завершения, запустил и забыл)
Этим я снимаю всю головную боль вообще. Если ответ ф-ции OK, то это полностью устраивает и в соответствии с логикой программы.
Но если ответ Error: Description bla-bla-bla
то
нужно вывести msgbox "Error: Description bla-bla-bla"
и этот msgbox придется весить на EXE тогда, а не на основную прогу, а этот EXE на каких нибудь вистах может вывести этот msgbox черт знает куда, напр. под низ всех окон (по опыту знаю, что так бывает, лечить это не тривиально), поэтому лучше, чтоб вывод msgbox был из-под основного приложения.

А есть вариат круче. Команда поступает по e-mail.
Т.е. клиентом является приложение, которое
1) Проверяет почту (pop3)
2) Складирует полученные письма mail1.eml, mail2.eml
3) Последовательно с ними разбирается, т.е. берет mail1, берет attachment, конвертирует attachment в чего надо
4) если конвертация удалась, то передает результат дальше
5) если не удалась, то создает задание послать Email с содержанием "Error: Description bla-bla-bla"
И вот в случае пункта 5, если буду делать Shell( EXE with parameters ,vb...) , то процедуру создания обратного мыла придется перевесить на EXE, а это уже покруче чем msgbox "Error: Description bla-bla-bla"
Не говоря о том, что клиент перейдет к обработке mail2.eml до того как полностью будет разобран mail1.eml, т.е. это спутает карты и существующий алгоритм.
Ну опять же, поскольку клиент, занимающийся mail-ами не имеет user-интерфейса, может делать
Result= Function()
и ждать, здесь это разумно.

Antonariy,

у меня тихо начинает ехать крыша и я начинаю задумываться о том что здоровье дороже.
Проект ваш
1) В IDE не запускается, т.е. main не работает
2) Как exe запускается, но при нажатии на кнопку start 10 jobs вылетает с ActiveX not able to create 429
Пытался зарегистрировать exe /regserver (больше ничего нет), даже в нормальном пути все одно 429
3) На попытаться чего-то осознать в коде при незапускаемом в IDE exe нет сил.
Наверно буду сдаваться.