• Status Assigned
  • Percent Complete
  • Task Type Bug Report
  • Category Application
  • Assigned To
  • Operating System Windows XP
  • Severity High
  • Priority Very Low
  • Reported Version Development
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Koda
Opened by ND - 02.05.2010
Last edited by Admin - 04.05.2010

FS#131 - Unable to insert embedded IE control

In version when I try to add an embedded IE control (Shell.Explorer.2) to a form Koda shows
‘Call to DllRegisterServer failed in

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.

Admin commented on 03.05.2010 15:49

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.

ND commented on 03.05.2010 16:10

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.

ND commented on 03.05.2010 18:02

Well, after creating a template my KXF contains
xml> <object type="TAObj" name="frmMain_htmInfo">

      <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>

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

Applet not registered


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.

Admin commented on 03.05.2010 21:24

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

  "AXName""String"Microsoft Web Browser

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.

Admin commented on 04.05.2010 07:06

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


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?

ND commented on 04.05.2010 10:16

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.

Admin commented on 04.05.2010 13:37

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.

ND commented on 04.05.2010 14:24

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.

Admin commented on 04.05.2010 18:16
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.


Available keyboard shortcuts


Task Details

Task Editing