Путь EXE из ActiveX Control

[SSecurity]

Всем привет!

Имеем проект, в нем форма, на форме ActiveX
Нужно, в коде ActiveX определить в каком месте сидит приложение, которое вызывает этот самый ActiveX.

Теперь зачем это нужно:
Имеется мысль о единой системе автообновления для программ, ну и ясный пень чтобы не делать для каждой системы подобные системы решил просто сделать контрол. Просто контрол ставим на форму указываем ЮРЛ откуда брать, и ИНИ-файл в котором хранить настройки. Думаю сразу становится понятно что если программ будет много то настройки автообновления лучше хранить не в папке с контролом - а в папке программы, которая обновляется ... для этого и нужно знать путь:)

НО, предвижу предложения во всех формах прописывать путь к EXE ну например строкой [ControlName].EXEPath = App.Path
идея интересная, но требует необходимости такой путь всегда прописывать ... а бывает влом.

Посему хочется увидеть предложения по реализации.
Первое что мне в голову приходит - получить от контрола hWnd и по нему определить процесс а через процесс определить путь к самому приложению.
Быть может есть путь значительно проще?

App.Path из самого контрола выдаст путь к расположению контрола, быть может есть у нас свойство чтоб по форме определить свойства приложения которое эту форму содержит?:):)

заранее благодарен за ответы:))))

С Уважением,
Сергей

[Хакер]

Первое что мне в голову приходит - получить от контрола hWnd и по нему определить процесс а через процесс определить путь к самому приложению.

А что если у приложения нет окон? Как же нету, — скажешь ты, — а где же тогда расположен UserControl. UserControl, — скажу я, — должен использоваться только когда он действительно user's control element, т.е. когда с ним непосредственно взаимодействует пользователь, а не просто так.

Быть может есть путь значительно проще?

Разумеется. Вызвать GetModuleFileName, передав 0.

[SSecurity]

А что если у приложения нет окон? Как же нету, — скажешь ты, — а где же тогда расположен UserControl. UserControl, — скажу я, — должен использоваться только когда он действительно user's control element, т.е. когда с ним непосредственно взаимодействует пользователь, а не просто так.

У меня они всегда будут, хотя бы потому что контрол я и выставляю сам при написании проекта:) ... Просвяти меня пожалуйста о наличии замечательного свойства InvisibleAtRuntime ... пользователь-телепат?

Разумеется. Вызвать GetModuleFileName, передав 0.

За это спасибо:)
кстати как его правильно использовать?

UPD: пример нашел разобрался, но про InvisibleAtRuntime всеравно просвяти, интересно мнение профессиональное услышать на этот счет.

[Хакер]

Просвяти меня пожалуйста о наличии замечательного свойства InvisibleAtRuntime ... пользователь-телепат?

Что ты хочешь о нём знать?

кстати как его правильно использовать?

По тупому:

Код: Выделить всё

Public Function GetProcessFileName() As String
    Dim ret     As Long
    GetProcessFileName = Space(255)
    ret = GetModuleFileName(0, buffer, 255)
    GetProcessFileName = Left$(GetProcessFileName, ret)
End Function

Чуть умнее:

Код: Выделить всё

Public Function GetProcessFileName() As String
    Dim ret     As Long
    Dim bs      As Long
    bs = 128
    Do
        GetProcessFileName = Space(bs)
        ret = GetModuleFileName(0, GetProcessFileName, bs)
        If ret = bs Then bs = bs * 2 Else Exit Do
    Loop
   
    GetProcessFileName = Left$(GetProcessFileName, ret)
End Function

[SSecurity]

по использованию нашел ) просто, интересно, зачем ЮзерКонтролу который должен работать с пользователем свойство которое скрывает его:)

Вот, за пример спасибо ))

[iGrok]

по использованию нашел ) просто, интересно, зачем ЮзерКонтролу который должен работать с пользователем свойство которое скрывает его:)

Оно скрывает его At Run-Time. Чтобы контрол не светился на форме запущенного приложения.

[SSecurity]

Оно скрывает его At Run-Time. Чтобы контрол не светился на форме запущенного приложения.

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

[iGrok]

Оно скрывает его At Run-Time. Чтобы контрол не светился на форме запущенного приложения.

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

Из этой фразы я так и не понял, понял ты или не понял. =)
На всякий случай уточню. Это св-во предназначено для того, чтобы сделать юзерконтрол невидимым в runtime, т.е. во время исполнения программы, но видимым во время разработки. Это нужно для контролов, которые не взаимодействуют напрямую с пользователем. Никому же нафиг не надо, чтобы пользователь видел загадочный "мониторчик" WinSock контрола где-нибудь в углу формы.. А вот для разработчика наличие визуального отображения этого контрола вполне себе удобно.

UPD:
О. Блин. Это, оказывается, я тормоз, а ты спрашиваешь совершенно с другой целью.. =)

Ну если применить всё это к вашей с Хакером беседе - не всё из того, что кем-то зачем-то сделано нужно применять.
Скажем так. Если контрол никак не взаимодействует с пользователем, то что мешает сделать его в виде класса?
А класс уже применять существенно удобнее. В частности, когда тебе понадобится добавить возможность обновления в программу в которой не будет ни одной формы (Вот только не надо говорить, что тебе никогда этого не понадобится. Когда-нибудь да понадобится. =) ) - с классом это можно будет сделать легко и непринуждённо. А вот с юзерконтролом...
Согласись, было бы намного удобнее, существуй тот же WinSock изначально в виде класса, а не в виде UserControl'а.

[Хакер]

А вы попробуйте сделать винсок в виде класса, поймёте, почему его сделали в виде UserControl-а.

[iGrok]

А вы попробуйте сделать винсок в виде класса, поймёте, почему его сделали в виде UserControl-а.

Согласен, винсок - неудачный пример. Но мне кажется, общую мысль я донёс..

[Хакер]

Общую мысль донёс я — бывают ситуации (и винсок тому пример), когда нечто, не требующее взаимодействия с пользователем, невыгодно оформлять в виде класса, а выгоднее сделать в виде контролла. Должна же в таком случае быть возможность его скрыть?

[SSecurity]

Смысл просто намного глубже, я конечно понимаю что некоторые вещи удобнее сделать классом, с этим я согласен ... но у меня к этому контролу ещё 8 форм взаимодействия с пользователем:) Задавать вопрос через MsgBox типа есть обновление - можно слить а можно и не сливать ... хотите? ... можно но в большинстве используемых проектов меня не устроит. Поскольку как мне кажется пользователь должен понимать, что я не обязываю его выполнять какие-либо действия, а лишь рекомендую, при этом, подробно разъясняя, что за этим может последовать ... кроме того, обновление версии может потребовать Акцептирование дополнительных соглашений, и ряд других действий которые набиваются в бАльшУщий контрол ))))

В последствии мне останется только динамически проверить установлен ли контрол автообновления, если нет, то и не запариваться - на компе такой возможности нет и система не будет автообновляться ... причем никак на работоспособность программы это не повлияет. Если же контрол есть, то автообновления будут осуществляться по рабочему алгоритму:) Ну и обновление OCX сделать не сложно - достаточно лишь куда-угодно скачать новой контрол с версией повыше и зарегить:)

[Хакер]

Ты так и не понял смысл свойства InvisibleAtRuntime

[SSecurity]

Я давно этим свойством пользуюсь и смысл, я понял:))))

Не показывать контрол при выполнении программы - соответственно контрол виден только разработчику:)