So i tried to open a specific form in vb 6 it says Path/File Access Error "filepath.log";
when i tried to open the log file this is the content
Line 2: Could not create reference: '{90F3D7B3-92E7-44BA-B444-6A8E2A3BC375}#1.0#0'.
Line 3: Could not create reference: '{6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.3#0'.
is there a way to open that specific form. I can open other forms in the project.
UPDATE
I tried Opening The .vbp project file in notepad and found the source of the reference.
Object={90F3D7B3-92E7-44BA-B444-6A8E2A3BC375}#1.0#0; actskin4.ocx
Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.3#0; COMCTL32.OCX
still i don't know how to fix this.
The VB6 IDE will generally refuse to display a form if one or more of the controls on the form cannot be loaded.
(You can of course view the .frm file in a text editor if you just need to read some detail of the code.)
Based on the combined information from the log file and the .VBP it seems clear that the two OCX files listed are not registered on your development PC. They may or may not be physically present.
As a first step, I would search on the PC to see if they can be located. Typically OCX files would be installed into the \Windows\SysWOW64 or \Windows\System32 folders, although other locations are definitely possible.
(COMCTL32.OCX is a Microsoft file, so that is probably where you'll find it. I don't know what the other one is).
Assuming you find those files, most likely you can register them in the location you find them (there are a lot of possibilities but that is probably an OK start).
If you can't locate them you will have to find some copy (from another developer maybe?) before you can proceed. If actskin4.ocx is a professional 3rd party control then probably it would have come with a proper installer which you should located & run.
Here are Microsoft's instructions to manually register a DLL / OCX.
All of the sudden the method by apps open the "select a file" dialog stopped working. For instance if I go to https://uploadfiles.io/, clicking on it does nothing, but the drag and drop works.
This is happening for apps as well, for example I just needed to resync my Google Drive and change the folder location, clicking in "browse" to select a folder does nothing. However, going to Notepad and file > open file works.
I've been searching for a while for the method, .dll, or something that is responsible for this without success. Anyone with a similar issue or more knowledge than what I have can point me in the right direction?
I'm not a naive English speaker so I am not sure if I'm not finding anything because I am not using the right names to search for it.
Windows 10 64b INSIDER PREVIEW FAST RING
I have exactly the same issue. It started somewhere between Friday and today. (Computer was shutdown for two weeks until friday night and before shutting down the problem did not exist.) I suspect some update. In addition to the mentioned issue I have trouble downloading files through Chrome. Edge and IE are downloading fine. Firefox will be installed to test this. It is consistent which apps are (not) allowed to spawn new windows. Apps in 'Program Files' seem OK while those in 'Program Files(x86)' differ. Of those in the (x86) folder OpenOffice is allowed to open a browse window, Adobe Reader is not. KeePass is allowed to open files, EventGhost is not. (changing install folder does not make a difference).
Since it is not clear how long this issue has been around I am hesitant to do a system restore. Also I believe that is a bandaid, not a solution. I am on the Fast Ring of updates.
I am trying to open a .chm file.
I downloaded the source, extracted it, and double clicked on Waffle.chm and clicked "Open" but no matter what element in the chm file I click, I get the message:
Navigation to the webpage was canceled.
What you can try:
Retype the address.
What's going on here?
Summary
Microsoft Security Updates 896358 & 840315 block display of CHM file contents when opened from a network drive (or a UNC path). This is Windows' attempt to stop attack vectors for viruses/malware from infecting your computer and has blocked out the .chm file that draw data over the "InfoTech" protocol, which this chm file uses.
Microsoft's summary of the problem: http://support.microsoft.com/kb/896054
Solutions
If you are using Windows Server 2008, Windows 7, windows has created a quick fix. Right click the chm file, and you will get the "yourfile.chm Properties" dialog box, at the bottom, a button called "Unblock" appears. Click Unblock and press OK, and try to open the chm file again, it works correctly. This option is not available for earlier versions of Windows before WindowsXP (SP3).
Solve the problem by moving your chm file OFF the network drive. You may be unaware you are using a network drive, double check now: Right click your .chm file, click properties and look at the "location" field. If it starts with two backslashes like this: \\epicserver\blah\, then you are using a networked drive. So to fix it, Copy the chm file, and paste it into a local drive, like C:\ or E:. Then try to reopen the chm file, windows does not freak out.
Last resort, if you can't copy/move the file off the networked drive. If you must open it where it sits, and you are using a lesser version of windows like XP, Vista, ME or other, you will have to manually tell Windows not to freak out over this .chm file. HHReg (HTML Help Registration Utility) Utility Automates this Task. Basically you download the HHReg utility, load your .chm file, press OK, and it will create the necessary registry keys to tell Windows not to block it. For more info: http://www.winhelponline.com/blog/fix-cannot-view-chm-files-network-xp-2003-vista/
Windows 8 or 10? --> Upgrade to Windows XP.
"unblocking" the file fixes the problem. Screenshot:
Win 8 x64:
just move it to another folder or rename your folder (in my case: my folder was "c#").
avoid to use symbol on folder name. name it with letter.
done.
In addition to Eric Leschinski's answer, and because this is stackoverflow, a programmatical solution:
Windows uses hidden file forks to mark content as "downloaded". Truncating these unblocks the file. The name of the stream used for CHM's is "Zone.Identifier". One can access streams by appending :streamname when opening the file. (keep backups the first time, in case your RTL messes that up!)
In Delphi it would look like this:
var f : file;
begin
writeln('unblocking ',s);
assignfile(f,'some.chm:Zone.Identifier');
rewrite(f,1);
truncate(f);
closefile(f);
end;
I'm told that on non forked filesystems (like FAT32) there are hidden files, but I haven't gotten to the bottom of that yet.
P.s. Delphi's DeleteFile() should also recognize forks.
The definitive solution is to allow the InfoTech protocol to work in the intranet zone.
Add the following value to the registry and the problem should be solved:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001
More info here: http://support.microsoft.com/kb/896054
Go to Start
Type regsvr32 hhctrl.ocx
You should get a success message like:
" DllRegisterServer in hhctrl.ocx succeeded "
Now try to open your CHM file again.
other way is to use different third party software. This link shows more third party software to view chm files...
I tried with SumatraPDF and it work fine.
I fixed this programmatically in my software, using C++ Builder.
Before I assign the CHM help file, Application->HelpFile = HelpFileName, I check to see if it contains the "Zone.Identifier" stream, and when it does, I simply remove it.
String ZIStream(HelpFileName + ":Zone.Identifier") ;
if (FileExists(ZIStream))
{ DeleteFile(ZIStream) ; }
There are apparently different levels of authentication. Most articles I read tell you to set the MaxAllowedZone to '1' which means that local machine zone and intranet zone are allowed but '4' allows access for 'all' zones.
For more info, read this article:
https://support.microsoft.com/en-us/kb/892675
This is how my registry looks (I wasn't sure it would work with the wild cards but it seems to work for me):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"UrlAllowList"="\\\\<network_path_root>;\\\\<network_path_root>\*;\\ies-inc.local;http://www.*;http://*;https://www.*;https://*;"
As an additional note, weirdly the "UrlAllowList" key was required to make this work on another PC but not my test one. It's probably not required at all but when I added it, it fixed the problem. The user may have not closed the original file or something like that. So just a consideration. I suggest try the least and test it, then add if needed. Once you confirm, you can deploy if needed. Good Luck!
Edit: P.S. Another method that worked was mapping the path to the network locally by using mklink /d (symbolic linking in Windows 7 or newer) but mapping a network drive letter (Z: for testing) did not work. Just food for thought and I did not have to 'Unblock' any files. Also the accepted 'Solution' did not resolve the issue for me.
Moving to local folder is the quickest solution, nothing else worked for me esp because I was not admin on my system (can't edit registery etc), which is a typical case in a work environment.
Create a folder in C:\help drive, lets call it help and copy the files there and open.
Do not copy to mydocuments or anywhere else, those locations are usually on network drive in office setup and will not work.
When deleting a folder that contains a file that is in use, it is common to see the following Windows 7 message,
"The action can't be completed because the folder or a file in it is open in another program."
I commonly have 10-20 programs open, 30-40 folders open, etc. In short, I have many executables running and many windows explorers open.
Does anyone know a simple trick to determine which program is using the file?
Does anyone know a simple trick to determine which file is blocking the delete operation?
This information would be highly useful to display in the Windows 7 'folder in use' dialog, but it is missing.
Consequently I have to close many of my open applications and folders to complete the delete operation. This is annoying because I have to re-open them after deleting them.
Have you seen this other question or this one?
I use to run ProccessExplorer and Find for the blocked folder.
Closing the application Malwarebytes allowed me to delete what I needed to via Windows Explorer.
I am fighting a bug which does not reproduce on my machine, but repeats every time on my client's machine. I've tried everything, and now I am looking for any debug data (or whatever) that IE8 leaves after a crash. Google and Microsoft searches gave me nothing. Where does Internet Explorer 8 store its crash dumps? It definetely sends something to Microsoft after a crash, how can I see it?
There is a post here that will show you how to generate a mini dump
http://www.vistax64.com/windows-updates/227276-mshtml-dll-internet-explorer-8-crash-3.html
To generate a minidump:
Download and install the "Debugging Tools" package
From the folder where you installed it, run WinDBG.exe as admin (right-click, "run as admin...").
Press F6, sort "by executable", find IEXPLORE.EXE, select, OK. (It's easier if you have only one instance of IEXPLORE running at this time.)
It'll spew out a whole bunch of numbers and eventually dump you on a prompt at the bottom of the page. Just type G and press enter. This attaches the debugger to the IEXPLORE process but then lets it "Go" and continue to do its thang.
Do whatever you need to do to repro the crash.
This time, a crash condition will cause the debugger to "break into" the IEXPLORE process and suspend all its actions. In other words, instead of seeing the same crash message you'll see the debugger take over and IEXPLORE will look like it's frozen.
Ignore all the spew again and wait for the prompt at the bottom of the WinDBG window, then type this:
.dump /m IE1.dmp
If you don't give it a full path, the IE1.dmp file will be created in the same folder where you installed the debugger package. If you zip up that minidump and upload it here, I or someone else may be able to dig more info out of it.