Oh, duh, it hosts itself inside that ViewletProxy that was previously
uninitialized :)
Are you doing this with Visual Studio running?
On Fri, Jun 27, 2008 at 6:52 AM, Curt Hagenlocher <[EMAIL PROTECTED]>
wrote:
> That "dir" error is a known problem with beta 3 -- and as you might
> imagine, sky-high in priority on our list of things to fix for beta 4.
>
> Viewlets appear to be user controls; you probably need to host one in a
> Form.
>
> On Fri, Jun 27, 2008 at 6:45 AM, Michael Foord <
> [EMAIL PROTECTED]> wrote:
>
>> Curt Hagenlocher wrote:
>>
>>> A bit of quality time with Reflector shows that there's a _viewletsProxy
>>> object which hasn't been initialized. You probably need to call
>>> VSLabFSICore.Viewlets.Init() first. It's static, and in the vslabfsicore
>>> module.
>>>
>>
>> Thanks Curt - your reflector-fu is greater than mine. I should spend some
>> quality time with it.
>>
>> Your advice gets me to the next step, I can make a GraphControl flash
>> momentarily into view (on creation), but attempting to show it causes
>> another explosion:
>>
>> C:\compile\VSLab>C:\compile\IronPython-2.0B3\ipy.exe -X:ExceptionDetail
>> viewlet.
>> py
>> Operation unavailable (Exception from HRESULT: 0x800401E3
>> (MK_E_UNAVAILABLE))
>> at System.Runtime.InteropServices.Marshal.GetActiveObject(Guid& rclsid,
>> IntPt
>> r reserved, Object& ppunk)
>> at System.Runtime.InteropServices.Marshal.GetActiveObject(String progID)
>> at VSLabFSICore.Viewlet.Show()
>> at GraphViewlet.GraphControl.Show()
>> at _stub_$28##26(Closure , CallSite , CodeContext , Object )
>> at _stub_MatchCaller(Object , CallSite , Object[] )
>> at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
>> at
>> Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite
>> site, T0 arg0, T1 arg1)
>> at S$2.Initialize(CodeContext )
>> at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName)
>> at IronPython.Hosting.PythonCommandLine.RunFile(String fileName)
>> EnvironmentError: Operation unavailable (Exception from HRESULT:
>> 0x800401E3 (MK_
>> E_UNAVAILABLE))
>>
>> The code that produces this is:
>>
>> import clr
>> clr.AddReference('vslabfsicore')
>> clr.AddReference('vslabviewlets')
>>
>> from VSLabFSICore import Viewlets
>> from GraphViewlet import GraphControl
>>
>> Viewlets.Init()
>> g = GraphControl()
>> g.Show()
>>
>> If instead of 'g.Show()' I attempt 'dir(g)' I get a very odd error!
>>
>> C:\compile\VSLab>C:\compile\IronPython-2.0B3\ipy.exe -X:ExceptionDetail
>> viewlet.
>> py
>> 'this' type cannot be an interface itself.
>> at System.RuntimeTypeHandle.GetFirstSlotForInterface(IntPtr
>> interfaceHandle)
>> at System.RuntimeType.GetInterfaceMap(Type ifaceType)
>> at
>> Microsoft.Scripting.Generation.CompilerHelpers.TryGetCallableMethod(Method
>> Info method)
>> at
>> Microsoft.Scripting.Generation.CompilerHelpers.FilterNonVisibleMembers(Typ
>> e type, MemberInfo[] foundMembers)
>> at IronPython.Runtime.Types.TypeInfo.MemberBinder.GetMember(Type type,
>> String
>> name, BindingFlags flags)
>> at
>> IronPython.Runtime.Types.TypeInfo.StandardResolver.ResolveMember(MemberBin
>> der binder, DynamicAction action, Type type, String name)
>> at
>> IronPython.Runtime.Types.TypeInfo.MemberResolver.ResolveMembers(MemberBind
>> er binder, DynamicAction action, Type type)
>> at IronPython.Runtime.Types.TypeInfo.GetResolvedMembers(MemberBinder
>> memberBi
>> nder, DynamicAction action, Type type)
>> at IronPython.Runtime.Calls.PythonBinder.ResolveMemberNames(CodeContext
>> conte
>> xt, PythonType type, PythonType owner, Dictionary`2 memberNames)
>> at IronPython.Runtime.Types.PythonType.GetMemberNames(CodeContext
>> context, Ob
>> ject self)
>> at IronPython.Runtime.Operations.PythonOps.GetAttrNames(CodeContext
>> context,
>> Object o)
>> at IronPython.Runtime.Builtin.dir(CodeContext context, Object o)
>> at _stub_$26##24(Closure , CallSite , CodeContext , Object , Object )
>> at _stub_MatchCaller(Object , CallSite , Object[] )
>> at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
>> at
>> Microsoft.Scripting.Actions.UpdateDelegates.Update3[T,T0,T1,T2,TRet](CallS
>> ite site, T0 arg0, T1 arg1, T2 arg2)
>> at S$2.Initialize(CodeContext )
>> at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName)
>> at IronPython.Hosting.PythonCommandLine.RunFile(String fileName)
>> ValueError: 'this' type cannot be an interface itself.
>>
>>
>> Incidentally, even when installed with VS Pro I can't get VSLab to work
>> *anyway* (this is Vista 64bit FWIW), so the code may not be ready for prime
>> time.
>>
>> I may try firing up reflector myself and see where it takes me.
>>
>> Michael Foord
>>
>>
>>> On Thu, Jun 26, 2008 at 2:58 PM, Michael Foord <
>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>> The viewlets that come with VSLab look *really* cool. They're
>>> based on F# so I decided to see if they could be used from IronPython.
>>>
>>> http://www.codeplex.com/vslab
>>>
>>> The dependencies are pretty hefty. You need F# installed *and*
>>> Managed DirectX (June 2008 SDK ~450mb seems to fulfil the dependency).
>>>
>>> To get at the viewlet assemblies you need Visual Studio Pro
>>> installed as well, but they can be extracted from the VSLabs msi
>>> installer without VS Pro.
>>>
>>> Ok, so with all the dependencies installed I attempt to use them -
>>> and *boom*. Anyone here got any ideas?
>>>
>>> IronPython 2.0 Beta (2.0.0.3000) on .NET 2.0.50727.1434
>>> Copyright (c) Microsoft Corporation. All rights reserved.
>>> >>> import clr
>>> >>> clr.AddReference('vslabfsicore')
>>> >>> clr.AddReference('vslabviewlets')
>>> >>> clr.AddReference('vslabcore')
>>> >>> from GraphViewlet import GraphControl
>>> >>> g = GraphControl()
>>> Traceback (most recent call last):
>>> File "<stdin>", line 1, in <module>
>>> File "vslabviewlets", line unknown, in .ctor
>>> File "vslabfsicore", line unknown, in .ctor
>>> File "System.Windows.Forms", line unknown, in get_Controls
>>> File "System.Windows.Forms", line unknown, in get_Properties
>>> SystemError: Object reference not set to an instance of an object.
>>>
>>>
>>> Interesting that the explosion is inside winforms. Referencing
>>> that assembly first makes knows difference.
>>>
>>> Michael Foord
>>>
>>>
>>> -- http://www.ironpythoninaction.com/
>>> http://www.voidspace.org.uk/
>>> http://www.trypython.org/
>>> http://www.ironpython.info/
>>> http://www.theotherdelia.co.uk/
>>> http://www.resolverhacks.net/
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>
>>
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/
>> http://www.trypython.org/
>> http://www.ironpython.info/
>> http://www.theotherdelia.co.uk/
>> http://www.resolverhacks.net/
>>
>> _______________________________________________
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
