Koda

Welcome to Koda bug tracker!

At the moment you can post bugreports or suggestions anonymously. But registered users have some benefits: attaching files, commenting, voting, tracking tasks e.t.c.

Due some asshole started spamming tracker, now (at least for some time) it’s not allowed to create anonymous tasks. Sorry for unconvenience.

In edit fields you can use DokuWiki syntax for formatting.

Tasklist

FS#131 - Unable to insert embedded IE control

Attached to Project: Koda
Opened by ND (doudou) - Sunday, 02 May 2010, 20:05 GMT+3
Last edited by Admin (Lazycat) - Tuesday, 04 May 2010, 17:48 GMT+3
Type Bug Report
Category Application
Status Assigned
Assigned To Admin (Lazycat)
Operating System Windows XP
Severity High
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

In version 1.7.2.8 when I try to add an embedded IE control (Shell.Explorer.2) to a form Koda shows error:
‘Call to DllRegisterServer failed in "shdocvw.dll"'

As consequence no AU3 code is generated for the control - although it shows on the form - and all attempts to open the definition file afterward fail with the same error message, so the only remaining option is to open KXF file as XML and remove the control manually.

Especially confusing is the fact that Koda wants to call DllRegisterServer at all. Why is it necessary? The DLL is already registered on the system, otherwise the control wouldn’t appear in the Koda’s object browser.

This task depends upon

Comment by Admin (Lazycat) - Monday, 03 May 2010, 19:49 GMT+3
  • Field changed: Status (Unconfirmed → Waiting feedback)

I tried to embed this control (the same OS) and it work fine for me.

DllRegisterServer is calling because AutoRegister option is set in underlying PSVHost component. This can be disabled though, and probably should be disabled by default as well. Btw, you can do that right now youself with control templates (Extras\Control Templates\readme.txt).

Also, Koda retreiving registered objects from registry, so in theory, control can be there, but not fully registered actually.

Comment by ND (doudou) - Monday, 03 May 2010, 20:10 GMT+3

The control is fully registered and it works just fine if I add it to the form in AU3 script directly.

DllRegisterServer fails (and will always fail on any platform) if the user isn't admin (or equivalent). I never work as admin on my machines and I know there are few people who don't either ;) .

I'll give it a try with the control template but vote for removal of the call in the defaults.

Comment by ND (doudou) - Monday, 03 May 2010, 22:02 GMT+3

Well, after creating a template my KXF contains this:

  <properties>
      <property name="Left" vt="Int16">264</property>
      <property name="Top" vt="Int8">8</property>
      <property name="Width" vt="Int16">385</property>
      <property name="Height" vt="Int16">321</property>
      <property name="Active" vt="True">True</property>
      <property name="InActiveColor" vt="Ident">clWhite</property>
      <property name="GUID" vt="String">8856F961-340A-11D0-A96B-00C04FD705A2</property>
      <property name="ServerOptions.TransferType" vt="Ident">ttFileServer</property>
      <property name="ServerOptions.ConnectType" vt="Ident">ctDirect</property>
      <property name="FileOptions.DefaultExt" vt="String">ocx</property>
      <property name="FileOptions.FileName" vt="String">shdocvw.dll</property>
      <property name="FileOptions.Folder" vt="String">C:\WINDOWS\System32\</property>
      <property name="AutoRegister" vt="False">False</property>
      <property name="AXName" vt="String">Microsoft Webbrowser</property>
      <property name="AXID" vt="String">Shell.Explorer.2</property>
      <property name="TabOrder" vt="Int8">1</property>
  </properties>



Koda however fails to open it with
Koda is unable to open this form, parser reports an error:

Applet not registered

</file>

But as I said the control works fine in forms inserted manually.

P.S.: this DokuWiki parser sucks - it fails to insert XML code properly.

Comment by Admin (Lazycat) - Tuesday, 04 May 2010, 01:24 GMT+3

Yours code is fail for me. But, here is copy from mine form, which work well for me:

<properties>
  <property name="Left" vt="Int8">72</property>
  <property name="Top" vt="Int8">56</property>
  <property name="Width" vt="Int16">162</property>
  <property name="Height" vt="Int8">116</property>
  <property name="Active" vt="True">True</property>
  <property name="InActiveColor" vt="Ident">clWhite</property>
  <property name="GUID" vt="String">{8856F961-340A-11D0-A96B-00C04FD705A2}</property>
  <property name="ServerOptions.TransferType" vt="Ident">ttFileServer</property>
  <property name="ServerOptions.ConnectType" vt="Ident">ctDirect</property>
  <property name="FileOptions.DefaultExt" vt="String">ocx</property>
  <property name="FileOptions.FileName" vt="String">ieframe.dll</property>
  <property name="FileOptions.Folder" vt="String">C:\WINDOWS\system32\</property>
  <property name="AutoRegister" vt="True">True</property>
  <property name="AXName" vt="String">Microsoft Web Browser</property>
  <property name="AXID" vt="String">Shell.Explorer.2</property>
  <property name="TabOrder" vt="Int8">0</property>
</properties>

Notice, that FileOptions.FileName targeting to another dll. I don't sure whose system is wrong :-)

Btw, what wrong with XML parser? Never had the problems with it, this is quite usual Geshi.

Comment by Admin (Lazycat) - Tuesday, 04 May 2010, 11:06 GMT+3

I tried on different machine, there it's similar yours (looks like because different IE versions), but still work:

<property name="GUID" vt="String">{8856F961-340A-11D0-A96B-00C04FD705A2}</property>
<property name="FileOptions.DefaultExt" vt="String">ocx</property>
<property name="FileOptions.FileName" vt="String">shdocvw.dll</property>
<property name="FileOptions.Folder" vt="String">C:\WINDOWS\system32\</property>
<property name="AXID" vt="String">Shell.Explorer.2</property>

So, the only noticeable difference as you see - GUID in your code have missed brackets. I tried to add them and your code work.

I wonder why? Koda just take section name under HKCR\CLSID section. Can you check your registry for 8856F961-340A-11D0-A96B-00C04FD705A2 section having brackets?

Comment by ND (doudou) - Tuesday, 04 May 2010, 14:16 GMT+3

Of course it has brackets, my KXF file shows them too (I told you: the DokuWiki parser had crippled the code). Again, the control functions perfectly when inserted manually in the AU3 script (or in a VB form for that matter), which wouldn't be possible with broken registry.

Comment by Admin (Lazycat) - Tuesday, 04 May 2010, 17:37 GMT+3

I tried to run Koda under slightly restricted user ("Power user"), and working with this object fine. But under highly restricted user seems I reproduced your problem. Unfortunatley, here is little chance for fast fix, since third-party component for handling objects is used.

Comment by ND (doudou) - Tuesday, 04 May 2010, 18:24 GMT+3

While proper fix isn't available, may I suggest a workaround? I mean, in case of such a problem Koda would display a placeholder for a control and at least generate the creation code - it's only two lines after all:

$objIE = ObjCreate("Shell.Explorer.2")
$ieCtrl = GUICtrlCreateObj($objIE, 264, 8, 385, 321)

In the current state one has to stop using Koda completely in projects where the error occurs and it's real shame.

Comment by Admin (Lazycat) - Tuesday, 04 May 2010, 22:16 GMT+3
I mean, in case of such a problem Koda would display a placeholder for a control and at least generate the creation code

I'll look. But here can be the problem to catch an error while control loading.

Loading...