COM automation в SPF

[Dmitry Yakimov-2]

Привет,

Сделал экспорт HYPE3 классов в automation.
В примере cvs:\~day\hype3\examples\com\automate осуществляется доступ к
ствойствам hype3 экземпляра из vbs скрипта.

Работает это все хорошо, кроме одного но - экспорт аттрибутов
осуществляется "чистый" - то есть безтиповых форт переменных.
То есть если написать:

ForthObj.testVar = "Hello, world!"
MsgBox ForthObj.testVar

В первой строке мы положим в переменную строку, а вот во второй получим
ее адрес, потому что форт сторона не хранит информацию о типе.

Я склоняюсь к тому чтобы сделать еще один вариант IDispatch интерфейса в
котором свойства будут отображаться на hype3 объекты, a la

ComInteger OBJ var1
ComString   OBJ var2

С проверкой типов при присваивании, взятии.

Или можно сделать по другому:
COMVAR var1
COMVAR var2

где var1 и var1 самые обычные variant's, поэтому доставание и сохранение
будет довольно простое. Вот только пользоваться этими переменными в
форте придется как вариантами.

Есть у кого-либо мысли по поводу?

Dmitry.

[Andrey Cherezov]

Добрый день, Dmitry Yakimov!

Ваше сообщение от 17.12.2006 19:36:

> Работает это все хорошо, кроме одного но - экспорт аттрибутов
> осуществляется "чистый" - то есть безтиповых форт переменных.
> То есть если написать:
>
> ForthObj.testVar = "Hello, world!"
> MsgBox ForthObj.testVar
>
> В первой строке мы положим в переменную строку, а вот во второй получим
> ее адрес, потому что форт сторона не хранит информацию о типе.
>
> Есть у кого-либо мысли по поводу?
>  

Раньше мы в форт-работе с COM засекали изменение глубины стека и считали
так:
если вызываемое слово возвращает два числа, то это строка, если одно -
то число.
(Так же и в str*.f) Этого достаточно в большинстве практических применений.

[Dmitry Yakimov-2]

Привет,

Andrey Cherezov wrote:

> Добрый день, Dmitry Yakimov!
>
> Ваше сообщение от 17.12.2006 19:36:
>  
>> Работает это все хорошо, кроме одного но - экспорт аттрибутов
>> осуществляется "чистый" - то есть безтиповых форт переменных.
>> То есть если написать:
>>
>> ForthObj.testVar = "Hello, world!"
>> MsgBox ForthObj.testVar
>>
>> В первой строке мы положим в переменную строку, а вот во второй получим
>> ее адрес, потому что форт сторона не хранит информацию о типе.
>>
>> Есть у кого-либо мысли по поводу?
>>  
>>    
> Раньше мы в форт-работе с COM засекали изменение глубины стека и считали
> так:
> если вызываемое слово возвращает два числа, то это строка, если одно -
> то число.
> (Так же и в str*.f) Этого достаточно в большинстве практических применений.
>  

Я это как раз применяю, при записи.
А вот при чтении не получится, нужно тип хранить.

Best Regards,
Dmitry Yakimov

[Andrey Cherezov]

Добрый день, Dmitry Yakimov!

Ваше сообщение от 18.12.2006 10:05:
>> если вызываемое слово возвращает два числа, то это строка, если одно -
>> то число
> Я это как раз применяю, при записи.
> А вот при чтении не получится, нужно тип хранить.
>  
А может универсальнее - getter сделать? Т.е. при записи тип понятен, а
при чтении вызывать getter, если он у этой переменной есть.
Или явер (прямо в исходнике):

ForthObj.testVar = "Hello, world!"
MsgBox ForthObj.testVar_get

Тогда при чтении тип результата определяется тем же способом - по
изменению глубины стека.
И вообще - не обязательно ведь, чтобы testVar была именно
форт-переменной класса VARIABLE.
Она может быть класса COM_VARIABLE :) - с двумя полями кода, например.
Как VALUE.

[Andrey Cherezov]

Моё сообщение от 19.12.2006 2:30:
> Или явер (прямо в исходнике):
>  
явер -> явно (опечатка)
> Тогда при чтении тип результата определяется тем же способом - по
> изменению глубины стека.
>  
Кстати, по-моему, при таком подходе к типизации - тип при чтении как раз
легче узнать, чем при записи.

[Dmitry Yakimov-2]

Привет,

Andrey Cherezov wrote:

> Добрый день, Dmitry Yakimov!
>
> Ваше сообщение от 18.12.2006 10:05:
>  
>>> если вызываемое слово возвращает два числа, то это строка, если одно -
>>> то число
>>>      
>> Я это как раз применяю, при записи.
>> А вот при чтении не получится, нужно тип хранить.
>>  
>>    
> А может универсальнее - getter сделать? Т.е. при записи тип понятен, а
> при чтении вызывать getter, если он у этой переменной есть.
> Или явер (прямо в исходнике):
>
> ForthObj.testVar = "Hello, world!"
> MsgBox ForthObj.testVar_get
>
> Тогда при чтении тип результата определяется тем же способом - по
> изменению глубины стека.
> И вообще - не обязательно ведь, чтобы testVar была именно
> форт-переменной класса VARIABLE.
> Она может быть класса COM_VARIABLE :) - с двумя полями кода, например.
> Как VALUE.
>
>  

А я еще проще сделаю  :) Будем хранить прямо в вариантах.
Класть будет совсем легко. Доставать тоже.
А пользоваться этими вариантами в  форте тоже несложно будет, я их в
соответствующие классы оберну.

Только вот вопрос. Делать строную типизацию или нет?
Поясню на примере:

Есть у нас

CComString OBJ myVar

Мы сделаем из vbs скрипта:
ForthObject.myVar = "tratata"

Это все просто и должно работать хорошо.
Но вот я делаю финт:
ForthObject.myVar = 12345

то есть присваиваю число. Как поступить в этом случае?
Можно сказать - тип несовместим. А можно всего одной winapi ф-ей
преобразовать число в тип принимающего варианта то есть в строку.

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

Но главный критерий - не наплодит ли вариант два трудных ошибок? А так
сказали что тип не совместим и все. Андрей, что думаешь?

Best Regards,
Dmitry Yakimov.

[Dmitry Yakimov-2]

Привет,

Так, залил это на CVS. Можно уже использовать в реальных приложениях,
API не изменится!
Работа с форт словами и переменными работает ОК как на чтение так и на
запись (любых типов!), в примере мы например два float числа получаем из
скрипта, очень легко отдаем результат наружу.

А возможностей море - например можно делать расчеты в форте и легко
передавать их сложному GUI написанному на дельфи например, можно
отладчик сделать на c# с кучей визуальных наворотов, а подключаться к
форту он будет по automation.
Ну и взаимодействие с web сервером тоже можно сделать.

Экспорт идет именно hype3 объектов, их можно создавать несколько.
Завалить простой даже STA сервер из скрипта теоретически невозможно,
если найдете такую возможность - дайте знать.

В общем пробуйте :)

p.s. COM объектные переменные я сделаю, но это будет довеском к
существующем коду, не более.

Andrey Cherezov wrote:

> Моё сообщение от 19.12.2006 2:30:
>  
>> Или явер (прямо в исходнике):
>>  
>>    
> явер -> явно (опечатка)
>  
>> Тогда при чтении тип результата определяется тем же способом - по
>> изменению глубины стека.
>>  
>>    
> Кстати, по-моему, при таком подходе к типизации - тип при чтении как раз
> легче узнать, чем при записи.
>
>  

Best Regards,
Dmitry Yakimov

[Andrey Cherezov]

Добрый день, Dmitry Yakimov!

Ваше сообщение от 19.12.2006 18:32:

> то есть присваиваю число. Как поступить в этом случае?
> Можно сказать - тип несовместим. А можно всего одной winapi ф-ей
> преобразовать число в тип принимающего варианта то есть в строку.
>
> Трудозатраты в обоих случаях по программированию одинаковы, по ресурсам
> машины - во втором немного больше.
> Второй вариант для программистов конечно удобнее, большая часть типов с
> большей чатью совместима. Все совместимо со всем, офигенна
> интероперабельность.
>
> Но главный критерий - не наплодит ли вариант два трудных ошибок? А так
> сказали что тип не совместим и все. Андрей, что думаешь?
>  

Вариант с бестиповыми переменными и автопреобразованием типов при
присваиваниях - так принято почти во всех скриптовых языках, поэтому так
привычнее и должно быть удобнее. Контроль типов можно оставить опционально -
т.е. в том слове, которое делает преобразование, предусмотреть flag IF ... -
это не усложнит реализацию (на первый взгляд).

[Andrey Cherezov]

Добрый день, Dmitry Yakimov!

Ваше сообщение от 19.12.2006 18:42:
> А возможностей море - например можно делать расчеты в форте и легко
> передавать их сложному GUI написанному на дельфи например, можно
> отладчик сделать на c# с кучей визуальных наворотов, а подключаться к
> форту он будет по automation.
>  
Да, у меня уже был случай, лет 5 назад, когда обращение через COM к форту
оказалось наиболее эффективным решением задачи: я тогда использовал Outlook
для работы с почтой, и действовала на нервы его неспособность справиться
с перекодировкой многих писем, когда кодировки явно не указаны. Я сначала
на встроенном бейсике написал перекодировщик, привязал его к кнопке на
тулбаре,
но скрипт тормозил зверски - минута или больше на одно письмо. Заменил
в скрипте функцию перекодировки на вызов SPF через COM - всё стало летать,
использовал несколько лет. (потом сделал еще проще: перешел на IMAP Eserv'а
и при выдаче заголовков клиенту просто подставлял правильную кодировку,
это и врожденную проблему NetscapeMail/Thunderbird решает тоже - её через
COM решить наверное не смог бы).
> Экспорт идет именно hype3 объектов, их можно создавать несколько.
> Завалить простой даже STA сервер из скрипта теоретически невозможно,
> если найдете такую возможность - дайте знать.
>
> В общем пробуйте :)
>  
Спасибо, при случае попробую. Может даже в Eserv встрою, если не
возражаешь ;)
Там уже давно есть необходимость взаимодействия между серверами Eserv
(в разных exe) между собой, т.к. в частности антиспамы могут быть запущены
только в одном из серверов, а использоваться должны из трёх. Сейчас это
решается
взаимодействием между серверами по TCP, а можно было бы сделать по COM.
И таких задач в Eserv хватает.