Если было понятно "с первого раза", то зачем создавать новый объект Shell Window, когда Рабочий стол всегда имеется?

Судя по всему, вы так и не поняли, что происходит в скрипте. В изначальном скрипте создаётся новое окно, скрытое (и никакой ссылки на рабочий стол там нет), а я использую существующее, в этом разница.

Почему у всех, только у Shell Window, который реализует IWebBrowser2 interface.

Это маловероятно, Рабочий стол — это такое же окно, как и другие окна Проводника, и его объект Shell Window также реализует IWebBrowser2.

Поднимаю тему.
Копаю дальше.
Выкладываю решение проблему с регистрация СОМ объекта WSC

• Дело было не в бабине, человек сидел в кабине(R)

Короче.
Обычный старый код WSC
файл COM_VBS.wsc

<?xml version="1.0" encoding="windows-1251" standalone="yes"?>
<?component error="true" debug="true"?>
<component>
<registration 
 progid="ServerVBS.WSC"
 classid ="{2DB3675C-29EE-470B-ADFC-7AB4C59C987F}"
 version="1.0"/>

<public>

  <property name="hash"><get/><put/></property>
</public>

<implements type="ASP"/>

<script language="VBScript"><![CDATA[
    ' --------------------------------------------------
dim a
    Function mem_(byval aa)
        a=aa
    End Function

]]></script>

<script language="JScript"><![CDATA[

var hash = {};

function get_hash() {
  if(arguments.length)
    return hash[arguments[0]];
  else
    return hash;
}

function put_hash() { 
  var key = arguments[0], prop = arguments[1];
  hash[key] = prop;
mem_(prop)
}





]]></script>
</component>

ремарка С элементами пробы пера добиться глобальной записи переменно как это совершается с проводником и с рабочим столом
и клиентский код на VBS
файл COM.vbs

'*************************************************
'*************************************************
'*************************************************
'*************************************************
'*************************************************
' Регистрация WSC производиться в ком строке от имени админа  
' regsvr32 требует этого. При этом происходи проверка правильности  кода в WSC  
'
'regsvr32 scrobj.dll /n /i:file:\\ваш полный путь к файлу\COM_VBS.wsc
'
' После этой регистрации все VBS коды могут обращаться к WSC не как к файлу а как к COM объекту
' старое обращение выглядело так 
'  Set wsc = GetObject("script:путь к файлу wsc\COM_VBS.wsc")
' теперь объявление этого СОМ объекта происходит по "НАСТОЯЩЕМУ"
' Set wsc =Createobject("ServerVBS.WSC")
'*************************************************
'*************************************************
'*************************************************
'*************************************************
'*************************************************
'*************************************************
option explicit

dim wsc



Set wsc =Createobject("ServerVBS.WSC")

WSH.echo typename(wsc) '- вывод информации вы виде GUID о зарегистрированной переменной "wsc"


wsc.hash("test") = "one" '-- создание нового "свойства test" и одновременная запись туда "one"
WSH.echo wsc.hash("test") '-- вывод результата из свойства "test" one

wsc.hash("test2") = "two" '-- создание нового "свойства test2" и одновременная запись туда "two"
WSH.echo wsc.hash.test2 '-- вывод результата из свойства "test2" two

wsc.hash("test3") = "three" '-- создание нового "свойства test3" и одновременная запись туда "two"
WSH.echo wsc.hash("test3") '-- вывод результата из свойства "test3" three

Set wsc =Nothing

Теперь к объекту progid="ServerVBS.WSC" можно обращаться в стандартном варианте как к "взрослому" СОМ.

Ну короче, я "всё узнал" (по крайней мере как я думаю).

• 1- В VB6 как сказано в верхнем посту (см линк от микрософта), что мол DCOM и траляляля...
  А на самом деле там реализуются статистические данные с помощью установок на форме.
  параметр
  Persistable
  0 иди 1.
  1 запоминает или в тексте данные в форме, любые хоть с переменных, или бинарные.
  0 не запоминает.
  по умолчанию 0.
  При 1 будет создаваться к OCX/EXE файлу файл кеша. И автоматом читается...

• 2-в VB.NET тоже есть такое.
  Но называется эта штука
  serialization
  xxxx://learn.microsoft.com/ru-ru/dotnet … lization/
  
  хххх://nweb42.com/books/visual-basic-ne … asic-net/
  
  Я проверил, пашет на ура.
  файлик быстро читается и пишется. Но можно сохранять и переменную.
  Есть там у VB.NET переменная похожая на VBS Dictionary.
  Так там я сохранял списками и fso и Dictionary и массивы, без применения файлов.
  При этом эта переменная пропадает при перезагрузки, как у проводника.
  А если с файлом то данные остаются даже после перезагрузки.

И кстати, в VB.NET  эта штуковина, заточена и на сетку, что бы передавать и в сетку данные через неё.
Т.е. обеспечивать связь с разными компами.

К сказанному выше.

ex0.vbs Считывает свой hwnd_1 и передаёт его  ex1.vbs.
В свою очередь ex1.vbs считывает свой hwnd_2 и передаёт по hwnd_1, в
ex0.vbs свой hwnd_2. После этого происходит общение на 2-ух независимых
процессах на cscrip.exe

teadrinker
Да нееее. Она всё правильно сделал "мне намёк".
Но сама конечно она тупая. Но намёк я понял.
Сейчас некогда писать код, но чувствую что там прокатит.
Намёк заключается в её словах о "pipe канале".
Если коротко.
cmd формирует у себя СВОЙ именной канал связи в консоле.
Вот в этом то и канале "pipe" и будут переговариваться между собой скрипты.
надо в скрипте применять операторы stdout  и stdin

teadrinker
ЧТЗ Как у меня в школе ЭТО переводится "Что и требовалось доказать".
Канал pipe не закрывается пока какая либо прога не  закроет "окно".
1- файл 1.vbs
...

   Dim StdOut
   Set StdOut = WScript.StdOut
      StdOut.WriteLine "передаю, получай! ТОЧКА ТИРЕ 123"
   Set StdOut = nothing
WScript.Quit 0  ' Успешное завершение

Сохраняйте файл в кодировке ANSI иначе слова "передаю, получай! ТОЧКА ТИРЕ" будет абракадабра.
Обратите внимание!!! в 1-ом файле нет операторов на чтение. Есть только запись в канал.
2- файл 2.vbs

   Dim StdIn
   Set StdIn = WScript.StdIn

   Dim cmd
      cmd = StdIn.ReadAll

msgbox "спасибо - получил  ==> " &  vbcrlf & vbcrlf & vbcrlf & cmd

Set StdIn = nothing
WScript.Quit 1  ' Успешное завершение

П.С. сохраните его в ANSI
Опять обратите внимание. Что во втором есть оператор только чтения из канала ... Но вывод инфы
происходит средствами не консоли а средствами VBS. т.е. окном VBS. Поэтому там (в инфе) нет и намёка на консоль CMD.
Это для страховки, мало ли чего там с каналами...
теперь можем писать общий файл.
3-RUN.vbs

Set Shell = WScript.CreateObject("WScript.Shell")

Shell.Run "%comspec% /c cscript  1.vbs | cscript  2.vbs ", 1, True  '-- окна консоли БУДЕТ видно, И окно vbs будет появляться
'Shell.Run "%comspec% /c cscript  1.vbs | cscript  2.vbs ", 0, True '-- окна консоли НЕ БУДЕТ видно, но окно vbs будет появляться  

В окне инфы будет строки на абракадабровом языке
Сервер сценариев Windows (Microsoft ®) версия 5.812
Copyright (C) Корпорация Майкрософт 1996-2006, все права защищены.

А уже ниже будет код посланный из первого скрипта второму.
так что через PIPE можно общаться между скриптами. при этом канал остаётся открытым, и управляем.
Ремарка.
В окне, инфы от второго файла в сверху надпись от самого файла "спасибо получил"
Потом ниже надпись абракадабры от микрософта что мол ЭТО ОН ТАКОЙ УМНЫЙ И ЕГО ВЕРСИЯ УМА...
А уже в самом низу инфа полученная (прочтённая) из общего канала PIPE консоли посланная первым скриптом.
"передаю, получай! ТОЧКА ТИРЕ 123"

teadrinker
самое интересное в ЭТОЙ схеме это то что, запускаются 2-а процесса, разные под разными Pid и hwnd.
Это видно в диспетчере задач. Но цепляются оба за один канал связи который их запустил.

teadrinker
Всё потом. Со временем проблемка.
Пока решил вопрос аброкадаброй.
надо добавить //nologo к первому vbs. Общая команда в RUN.VBS должна быть такой.

'Shell.Run "%comspec% /c cscript //Nologo 1.vbs | cscript  2.vbs ", 1, True
Shell.Run "%comspec% /c cscript //Nologo 1.vbs | cscript  2.vbs ", 0, True

или в самой консоле

cscript //Nologo 1.vbs | cscript  2.vbs

тогда будут только данные и не каких абракадбр.

teadrinker
Вот простой при простой пример банального общения между скриптами.
Смысл заключается в том, что в скрипт посылается аргумент, который вторым скриптом отлавливается и выдаётся им сообщение.
Но сообщение появляется не в самой винде а в скрипте который давал этому скрипту аргумент.
Вот как это выглядит.
имеется 2-а скрипта 1.vbs и 2.vbs. У них там только одна функция. Это показывать время в секундах.
У всех есть функция

WScript.Echo(Conv(strOutput))

Функция Conv() это перекодировка из формата 1251 в формат 866 доса. Потому что внутри канала PIPE всегда происходит выход по кодировки 866. И поэтому виндовые окна показывают абрукадабру.
Вот именно ЭТА функция WScript.Echo выводи сообщение по консольному каналу PIPE . Это окно в скрипте "2" не появляется, но оно посылает ответ в консольный канал ответ. В это время скрипт 1 читает функцией StdOut.RadAll() всё что залетело в канал. И поэтому она читает то что послал функцией   WScript.Echo второй скрипт.
Всё банально и просто.
По аргументу засылаешь в 1-ый скрипт данные, а по StdOut читаешь выход от 2-ого скрипта.
Можно было запустить и только 1.vbs скрипт, но тогда надо было бы городить способ посылки аргумента. А так с общим файлом start проще это было сделать. И наглядно одновременно.
1.vbs

option explicit

if Wscript.Arguments.Item(Wscript.Arguments.Count-1)="WRITE" then
call Write_
elseif Wscript.Arguments.Item(Wscript.Arguments.Count-1)="READ" then
call Read_
End if


'================================
'================================
'================================

Sub Read_()

Dim objShell, oExec, strOutput, strPipeCmd

strPipeCmd = "Cscript //Nologo //I  " & Chr(34) & CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName) & Chr(34) & "\2.vbs " & Chr(34) & "WRITE" & Chr(34) 
'msgbox strPipeCmd
Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
strOutput = oExec.StdOut.ReadAll()
WScript.Echo(Conv(strOutput))
WScript.Quit 0  ' Успешное завершение
end sub
'=================================
'=================================
'=================================
'=================================
'=================================
'=================================

Sub Write_()
Dim objShell, oExec, strOutput, strPipeCmd
Dim FSO
Set FSO = CreateObject("Scripting.FileSystemObject")
strPipeCmd = "Cscript //Nologo //B " 
Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
strOutput = oExec.StdOut.ReadAll()
WScript.Echo("скрипт 1.vbs отвечает: " & Now())
WScript.Quit 0  ' Успешное завершение
end sub

'=================================
'=================================
'=================================
'=================================
'=================================

function Conv(byval txtx)
 Dim objWshShell1,objStream
set objWshShell1 =CreateObject("WScript.Shell")
set objStream =CreateObject("ADODB.Stream")
    With objStream
        .Charset = "Windows-1251"
        .Open
        .WriteText txtx 
        .Position = 0
        .Charset = "cp866"
Conv = .ReadText
.Close
 End With
set objStream =nothing
set objWshShell1 =nothing
end function

файл 2.vbs

option explicit


if Wscript.Arguments.Item(Wscript.Arguments.Count-1)="WRITE" then
call Write_
elseif Wscript.Arguments.Item(Wscript.Arguments.Count-1)="READ" then
call Read_
End if

'=================================
'=================================
'=================================
'=================================
'=================================
'=================================

Sub Write_()
Dim objShell, oExec, strOutput, strPipeCmd
Dim FSO
Set FSO = CreateObject("Scripting.FileSystemObject")
strPipeCmd = "Cscript //Nologo //B " 
Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
'oExec.StdIn.Write("didididd")
strOutput = oExec.StdOut.ReadAll()
WScript.Echo("скрипт 2.vbs отвечает: " & Now())
WScript.Quit 0  ' Успешное завершение
end sub

'=================================
'=================================
'=================================
'=================================
'=================================
'=================================

Sub Read_()
Dim objShell, oExec, strOutput, strPipeCmd
strPipeCmd = "Cscript //Nologo //I  " & Chr(34) & CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName) & Chr(34) & "\1.vbs " & Chr(34) & "WRITE" & Chr(34) 
'msgbox strPipeCmd
Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
strOutput = oExec.StdOut.ReadAll()
WScript.Echo(Conv(strOutput))
WScript.Quit 0  ' Успешное завершение

end sub
'=================================
'=================================
'=================================
'=================================
'=================================
'=================================



function Conv(byval txtx)
 Dim objWshShell1,objStream
set objWshShell1 =CreateObject("WScript.Shell")
set objStream =CreateObject("ADODB.Stream")
    With objStream
        .Charset = "Windows-1251"
        .Open
        .WriteText txtx 
        .Position = 0
        .Charset = "cp866"
Conv = .ReadText
.Close
 End With
set objStream =nothing
set objWshShell1 =nothing
end function

общий файл который управляет всеми данными.
start.vbs

option explicit
Dim strPipeCmd, objShell, oExec, strOutput
Dim A_

strPipeCmd = "Cscript //Nologo //I  " & Chr(34) & CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName) & Chr(34) & "\1.vbs " & Chr(34) & "WRITE" & Chr(34) 

Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
strOutput = oExec.StdOut.ReadAll()
Set objShell = Nothing
Set oExec =  Nothing
'----- операция WRITE " =========
A_=Conv(strOutput)
WScript.Echo(A_)

strPipeCmd = "Cscript //Nologo //I  " & Chr(34) & CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName) & Chr(34) & "\1.vbs " & Chr(34) & "READ" & Chr(34) 
Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
strOutput = oExec.StdOut.ReadAll()
A_=Conv(strOutput)
WScript.Echo(A_)



'============================
'============================
'============================
strPipeCmd = "Cscript //Nologo //I  " & Chr(34) & CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName) & Chr(34) & "\2.vbs " & Chr(34) & "WRITE" & Chr(34) 

Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
strOutput = oExec.StdOut.ReadAll()
Set objShell = Nothing
Set oExec =  Nothing
'----- операция WRITE " =========
A_=Conv(strOutput)
WScript.Echo(A_)

strPipeCmd = "Cscript //Nologo //I  " & Chr(34) & CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName) & Chr(34) & "\2.vbs " & Chr(34) & "READ" & Chr(34) 
Set objShell = wscript.createobject("wscript.shell")
Set oExec = objShell.Exec(strPipeCmd )
strOutput = oExec.StdOut.ReadAll()
A_=Conv(strOutput)
WScript.Echo(A_)





'============================
'============================
function Conv(byval txtx)
 Dim objWshShell1,objStream
set objWshShell1 =CreateObject("WScript.Shell")
set objStream =CreateObject("ADODB.Stream")
    With objStream
        .Charset = "Windows-1251"
        .Open
        .WriteText txtx 
        .Position = 0
        .Charset = "cp866"
Conv = .ReadText
.Close
 End With
set objStream =nothing
set objWshShell1 =nothing
end function

В этом коде постепенно перебираются аргументы, WRITE и READ для обоих файлов и
в ответе видно как они внутри себя переговариваются между собой.
Но этот простой пример показывает что PIPE канал организуется во всех консольных приложениях.
Например прога diskpart или Powershell
Все они могут выдавать VBS скрипту ответы по его запросу, командой StdOut и StdIn
Хотел для наглядности общения между работающими 2-я скриптами написать интерактивное общение, но "долбёжки много".
Потому что надо было для наглядности выводить окно "HTA", например с часами и от туда из разных окон выхватывать время и торомзит часы, с потомщью общего файла "start.vbs".
А результат всё равно будет такой же как и в ЭТОМ моём примере.
НОНОНОНО..
Т.к. в этом примрее показано как можно, НО с примером проводник намного проще , по причине малого кода. ПЛЮС, этот СОМ объект всеяден для других языков, когда как этот мой пример заточен только для VBS и его уже не сунуть в VB.NET-->
Пример всеядности VBS с VB.NET
https://forum.script-coding.com/viewtop … 73#p163073
Там VBS засунут в "планировщик задачь", и по времени планировщика
запускается, делает проверки и посылаем месягу в "проводник" Переодичеки по времени 1-3 минуты прога VB.NET опрашивает "проводник" и выдаёт в трее вина окно с уведомлением, в стандартном виде.
...
Вот ЭТО я бы не смог сотворить методом котрый привёл тут (долбёжки много). А с "провоником" как нефига делать .
Вот и возникает вопрос "А нафига козе баян?" , если есть "проводник"?

teadrinker
1- с помощью проводника
2- пример применения проводника с разными языковыми скриптами ->
https://forum.script-coding.com/viewtop … 76#p163076

teadrinker
Вы по поводу PIPE ?
1- как и в моём примере с проводником. Прописывается таймер по которому происходит опрос скрипта с выставлением ему Аргументов ... В моём тут примере аргумент был WRITE или READ.
2- В примере "тут", в файлах 1.vbs и 2.vbs если ВЫ внимательно присмотритесь, при разных аргументах (write/read) , создаётся PIPE  канал различный, относительно аргументоа. Что я имею ввиду? Например файл 1.vbs .При аргументе READ создаётся канал с 2.vbs с поcылкой ему аргумента    WRITE. А при аргументе WRITE создаётся просто канал PIPE без всего, и даже без указания получателя. Т.е. просто пустой канал, в который будет посылаться месяга Wscript.echo. А получатель этой месяги будет тот кто отправил ему этот аргумент WRITE. Вот присмотритесь внимательно как ЭТО организовано. Тогда вы поймёте как это работает.
Я так понял на этом примере, что

cscript.exe

создают между собой один и тот же канал связи. При этом команда

StdIn.Write

полностью игнорируется , а общение происходит ТОЛЬКО по внутренним функциям самой

cscript.exe

.
В этом примере функция   

StdOut.ReadAll()

ловит в канале то что отправила туда функция Wscript.echo. Заметьте, не 

StdIn.Write

  а именно Wscript.echo в пустоту, в пустой канал. Но всё равно тот кто послал аргумент WRITE, ловит в этой пустоте с помощью консольной

StdOut.ReadAll()

, всё что выдала Wscript.echo второго скрипта.
...
Ну короче. схема такая. в обоих скриптах стоят таймеры и по ним и по ответам, переговариваются между собой эти скрипты. Аргументов можно наслать в линию много. Первый аргумент это типа , читать/отвечать, второй какие параметры или какие функции задействовать т.д.. А т.к. каналы у скриптов единоличные (как я понял именной канал PIPE у

cscript.exe

всего один ) , то ловить от туда могут все, не зависимо от скрипта. Главное что бы эти левые скрипты создали/вошли_туда  с помощью

cscript.exe

.
...
Но заниматься этой фигнёй мне в лом - "долбёжки много". Да и рядом есть "проводник".
Но "проводник", тоже оказался не чудо-юдо. А обычный пересыльщик текстовых посланий. Если вы будите через него слать объекты, то и ловите этим же языковым скриптом этот объект. Этот объект не будет распознаваться другим скриптовым языком. Что я и обнаружил при связывании VBS с VB.NET через него.
Я даже для верности изготовил свою DLL в VB.NET с регистрацией её, которая по прототипу Dictionary могла списки в себе организовывать, да не простые а с объектмами, т.е. всеядная такая- глотала всё. VBS со скоростью света её хавала и посылал туда объект. И если ловит его второй VBS, то там нет проблем. То этот объект (котороый был впихнут в dictionary первым VBS) появлялся и во втором VBS.  А вот эта же библиотека - родная для VB.NET , не смогла его правильно послать в такой же VB.NET. Т.е. у разных скриптов разное представление типов данных. Один тип остался стандартен , это текст, что я и использовал с проводником. Т.е.
вывод был таков.
ВЫВОД 
Если для разных скриптовых языков нет стандарта по типу данных, кроме как текст, то нафига городить огороды, когда есть готовый "почтовый ящик", который постоянно в работе без лишней регистрации его в вине?

teadrinker
"Человек, ищет где глубже." В данной ситуации, если бы не было "проводника", то пришлось бы ЭТОЙ "фигнёй" заниматься. Но опять же, из-за "глубины", то всё равно я бы выбрал бы "глубину", с изготовлением своего СОМ на VB6. Запустил бы его как "сервис", постоянно работающий, и он бы был бы почтальоном для всех. Кстати я сейчас именно этим и занят.
Установил себе в "ветку" (см тему о не убиваемом вине) VB6 и пробую. Там смотрю как и что там регистрируется. При этом в него (в VB6 ActiveX) , засунул свою DLL всеядную (Dictionary) сделанную на VB.NET. Короче. Есть dll компилированная на VB.NET. Из-за того что она сделана на VB.NET, она кастрированая. Кастированная по причине того что она не настоящая СОМ. VB.NET не умеет делать настоящие СОМ, и поэтому она полурегистрированная в вине. Для того что бы она была настоящая СОМ, её все советуют засунуть в VB6 и обернуть настоящей СОМ с регистрацией. Проверил - пашет. ремарка : На VB.NET потому что там запросто, запихиваются объекты в Dictionary.   . Потом (после VB6), с помощью MMC создаётся сервис для этого СОМ. И он запускается в вине как и запускается "проводник". И к нему (к моему СОМ) можно обращаться всем скриптам, как будто это "проводник".
....
Но связывать каждый скрипт, по PIPE, это морока, по сравнению с СОМ (сделал один раз и забыл) .
Если коротко. PIPE мало изучен и поэтому я и другие его обходим стороной. Тем более что "почтальон"  PIPE разностит, только тексты.