| View previous topic :: View next topic |
| Author |
Message |
vdsalchemist
Admin Team
Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA
|
 Posted: Thu Mar 22, 2007 12:25 am Post subject: |
 |
|
At the binary level there is no difference between a OCX file and a DLL file. However the OCX file can be thought of as a special purpose DLL. They are both Portable Executable(PE) files that export functions. This primary difference is how and what functions are being exported. Most OCX files do not export functions that can be readily accessed with out going through OLE. Also OCX files was the first in process way that OLE controls were packaged and are a left over from Visual Basic 4.0... They really should not be used today since they are actually a DLL and there are just no techical reason to keep with the OCX file extention. If you look at both a OCX file and a DLL file they will have the same header and layout. For that matter a Exe, DLL, and OCX are all the same with just small differences such as DLL and OCX files export functions while Exe's import functions. Anyway I could go on and on but I think this is enough for now.
_________________
Home of
Give VDS a new purpose!
 |
|
| Back to top |
|
 |
cnodnarb
Professional Member
Joined: 11 Sep 2002
Posts: 768
Location: Eastman, GA
|
| Posted: Fri Mar 23, 2007 12:26 am Post subject: |
|
|
Awesome. That gives me a few ideals. Thanks!
Brandon |
|
| Back to top |
|
|
jules
Professional Member
Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK
|
| Posted: Fri Mar 23, 2007 3:32 pm Post subject: |
|
|
| dragonsphere wrote: | Jules,
Why are you trying to change the path to the ocx from using the environment variable to using a hardcoded value? Especially since the ocx is in the system path anyway? |
Because the VDS 5 IDE (and the current official version of the VDS 5 runtime, and a lot of other Delphi programs that incorporate the same free bit of code) read this value from the registry and try to use it to load the OCX without expanding the string first. This gives rise to an error, since %SYSTEMROOT% literally is not a valid path. Since we can't change the code in VDS 5, I thought we could try to change the registry so that it contains what VDS 5 expects it to contain instead.
_________________
The Tech Pro
www.tech-pro.net |
|
| Back to top |
|
|
PGWARE
Web Host
Joined: 29 Dec 2001
Posts: 1567
|
| Posted: Fri Mar 23, 2007 5:09 pm Post subject: |
|
|
| Jules is right, its a temporary solution to 'fix' the problem with the IDE from loading help files in Vista. I haven't found another work around, other than opening the help file directly instead of from the IDE. |
|
| Back to top |
|
|
NathanH
Valued Newbie
Joined: 05 Sep 2001
Posts: 32
|
| Posted: Wed Apr 18, 2007 7:06 pm Post subject: Working now... |
|
|
So in Vista I went to the key HKEY_CLASSES_ROOT\CLSID\{ADB880A6-D8FF-11CF-9377-00AA003B7A11}\InprocServer32
I Right-Clicked on InprocServer32 and clicked Permissions
I clicked Advanced, then Owner tab, then changed owner to me by clicking my name, checking 'Replace owner on subcontainers and objects'
and clicking Apply (not ok yet).
On the permissions tab I double-clicked my name, checked 'full control' and pressed Okay. Next checked 'Include inheritable...' AND 'Replace all existing inhertable permissions...' and presed OK.
Now I was able to change the %systemroot% to C:\Windows mentioned by Jules.
The help menu is back from within VDS (and more importantly the CTRL-F1 is working). |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
@vdsworld