Возможна ли работа с классами .NET Framework ?
- Автор темы Luke
- Дата начала
Ругается на строку
:
Видимо ошибка в строке
, вот как её исправить незнаю.
Код:
$file = $oreader.Create("x.xml")
Код:
Variable must be of type "Object".:
$file = $oreader.Create("x.xml")
$file = $oreader^ ERRORВидимо ошибка в строке
Код:
$oreader = ObjCreate ("XmlReader")
- Сообщения
- 4,020
- Репутация
- 626
попробуй тогда так
или
не знаю точно какая из конструкций отвечает за этот код на VB
Добавлено:
Luke [?]
Добавлено:
да. по всей видимости ты прав и объект не создается. @error возвращает какую то ересь
Код:
$oreader = ObjCreate ("XmlReader")
$fs = FileRead('x.xml')
$file = $oreader.Create($fs)или
Код:
$oreader = ObjCreate ("XmlReader")
$fs = FileOpen('x.xml', 0)
$file = $oreader.Create($fs)не знаю точно какая из конструкций отвечает за этот код на VB
Код:
Dim fs As New FileStream("C:\data\books.xml", FileMode.OpenOrCreate, FileAccess.Read, FileShare.Read)
' Create the XmlReader object.
Dim reader As XmlReader = XmlReader.Create(fs)
End Sub 'FileStream
Сообщение автоматически объединено:
Luke [?]
и
как бы не совсем совместимы. на какую строку ругается, на той и ошибка.
Добавлено:
Сообщение автоматически объединено:
да. по всей видимости ты прав и объект не создается. @error возвращает какую то ересь
Уважаемый, Luke
пройдите по этой ссылке
http://msdn.microsoft.com/ru-ru/library/ms229335.aspx
и поищите интересующий Вас класс, и обращайтесь при создании объекта к нему по полному имени класса
Добавлено:
В Вашем случае похоже System.Xml.XmlReader
доступ к классам NET Framework, осуществляется по средствам строго определения, следуя всей иерархии классаLuke сказал(а):
пройдите по этой ссылке
http://msdn.microsoft.com/ru-ru/library/ms229335.aspx
и поищите интересующий Вас класс, и обращайтесь при создании объекта к нему по полному имени класса
Добавлено:
Сообщение автоматически объединено:
В Вашем случае похоже System.Xml.XmlReader
Можно пример как с ними работать ?. Пробовал System, System.Xml - все равно ошибка
Вычитал что нужный класс надо сначала зарегистрировать как СOM - сервер так:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>regasm System.XML.dll /tlb:System.XML.tlb
Зарегистрировал, всё равно не работает, что ещё надо не пойму.
Вычитал что нужный класс надо сначала зарегистрировать как СOM - сервер так:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>regasm System.XML.dll /tlb:System.XML.tlb
Зарегистрировал, всё равно не работает, что ещё надо не пойму.
Luke, Очень озадачен поднятым Вами вопросом...
И действительно - здесь не все так просто...
Пытаюсь "вкурить" в чем дело, но пока безрезультатно,
если что вымучаю отпишусь обязательно.
есть в этом доля правды (доля) там речь идет о VBScript через WBSH
э-т отдельная вотчина
Теоретически все компоненты .NET FrameWork уже зарегистрированы.
Так как скомпилированные приложения написанные на том-же VB.NET, не требуют никакой регистрации для того чтобы пользоваться классами NET Framework. (сборка System.xml - вряд ли исключение)
Хотя черт ее разберет, я хоть и довольно опытный "дотнетчик" но во многие фундаментальные моменты не вникал (а надо бы)
Суть такова, есть несколько вариантов:
1) Встроенная функция AutoIT - ObjCreate видимо как-то своеобразно подключается/захватывает COM-объект, в отличии от ее аналогов в "полноценных ООП языках"(C#, VB.NET, Java). Их компилятор сам решает кучу вопросов связанных с DCOM, DOM, OLE и прочими прелестями COM-технологии. От прогера необходимо лишь подключить необходимую сборку.
2) Мы не правильно "захватываем" объект, н/п открытая книга Office Excel хватается как "Excel.Application", хотя в OLE зарегано вобще "что-то с чем-то" а именно "Office (Microsoft Office 12.0 Object Library) \ OfficeDataSourseObject"
(если я правильно определил - там тож.черт ногу сломит)
3) И есть еще одна догадка... у xmlReader, так-же как StreamReader в .NET есть ряд методов которые требуют чтобы язык предусматривал перегрузку операторов (перегрузку методов в данном случае), возможно что некоторые классы могут использоваться только NET-языками ,и AutoIT это просто не под силу.
И действительно - здесь не все так просто...
Пытаюсь "вкурить" в чем дело, но пока безрезультатно,
если что вымучаю отпишусь обязательно.
http://forum.script-coding.info/viewtopic.php?id=1139 - тоже почитал,
есть в этом доля правды (доля) там речь идет о VBScript через WBSH
э-т отдельная вотчина
Теоретически все компоненты .NET FrameWork уже зарегистрированы.
Так как скомпилированные приложения написанные на том-же VB.NET, не требуют никакой регистрации для того чтобы пользоваться классами NET Framework. (сборка System.xml - вряд ли исключение)
Хотя черт ее разберет, я хоть и довольно опытный "дотнетчик" но во многие фундаментальные моменты не вникал (а надо бы)
Суть такова, есть несколько вариантов:
1) Встроенная функция AutoIT - ObjCreate видимо как-то своеобразно подключается/захватывает COM-объект, в отличии от ее аналогов в "полноценных ООП языках"(C#, VB.NET, Java). Их компилятор сам решает кучу вопросов связанных с DCOM, DOM, OLE и прочими прелестями COM-технологии. От прогера необходимо лишь подключить необходимую сборку.
2) Мы не правильно "захватываем" объект, н/п открытая книга Office Excel хватается как "Excel.Application", хотя в OLE зарегано вобще "что-то с чем-то" а именно "Office (Microsoft Office 12.0 Object Library) \ OfficeDataSourseObject"
(если я правильно определил
- там тож.черт ногу сломит)3) И есть еще одна догадка... у xmlReader, так-же как StreamReader в .NET есть ряд методов которые требуют чтобы язык предусматривал перегрузку операторов (перегрузку методов в данном случае), возможно что некоторые классы могут использоваться только NET-языками ,и AutoIT это просто не под силу.
- Сообщения
- 4,020
- Репутация
- 626
