-
Jul 8th, 2018, 05:48 AM
#1
Thread Starter
Lively Member
[RESOLVED] Access Denied
I seem to have been cursed with this problem ever since I've been using Visual Basic and I'd be most surprised if I'm the only one so affected. It occurs randoimly when I attempt to save a change to a VB6.0 program I've been working on. There will be many occasions when I can make numerous changes to a program in a session and recompiling will take place normally each time as expected, but then there will be other times when I am able to make just one change and recompile before the dreaded message appears when I attempt a second recompile.
To overcome the problem I have to reboot and it's then fine - for at least one further recompile.
Does anyone know what might be causing this problem and is there a fix for it? I've looked in the registry but haven't been able to find anything there. I'm using 64-bit Windows 10 Professional but I had exactly the same problem with 32-bit Windows XP.
Thank you for any assistance.
-
Jul 8th, 2018, 05:58 AM
#2
Re: Access Denied
Maybe you have something in your program that is not terminating properly when you run it causing something to be left in memory resulting in your error message. Check task manager the next time you see the message and see if there is any trace of your program running there if so then that is the likely problem.
For the record I have been using VB5/6 for 20 years or so. and have did so under multiple OS and don;t think I have ever ran into the issue you describe. I'll sometimes have a project actively open, making changes and test running it all day with hundreds of changes along the way and multiple compiles. It all just works as expected unless there is an issue in the code.
-
Jul 8th, 2018, 09:34 AM
#3
Re: Access Denied
DataMiser may be spot on. Definitely verify that. If the app is running, it can't be overwritten -- double check with Task Manager.
If the app isn't running when you are trying to recompile, does changing the exe name or destination folder allow the recompile to happen? Do you always run VB elevated?
Another slight possibility could be antivirus (AV) protecting the file. At my job, we have another layer of AV that can prevent recompiling the exe if the version number wasn't changed in project properties before recompiling attempted. Your problem sounds like it could be a scenario where another app may have your exe locked which makes me think of AV.
-
Jul 8th, 2018, 10:57 PM
#4
Thread Starter
Lively Member
Re: Access Denied
Originally Posted by DataMiser
Maybe you have something in your program that is not terminating properly when you run it causing something to be left in memory resulting in your error message. Check task manager the next time you see the message and see if there is any trace of your program running there if so then that is the likely problem.
For the record I have been using VB5/6 for 20 years or so. and have did so under multiple OS and don;t think I have ever ran into the issue you describe. I'll sometimes have a project actively open, making changes and test running it all day with hundreds of changes along the way and multiple compiles. It all just works as expected unless there is an issue in the code.
Thanks for your replay, DataMiser. I've been using them for about the same length of time and VB3.0 before that. One thing I always do within my VB programs is unload forms correctly; that is, I always Set the form (full form name) to equal Nothing after carrying out the Unload statement (using Me. I wonder of I should use the full name there too?). I have always been under the impression that using Nothing releases the form's memory usage. I am currently working on a program that is effectively two programs in one and I use the Shell function from a 'header' form to select one program or the other. I have just modified both programs - and one recompiled without incident while the other brought up the Access Denied message. In both instances, I immediately checked Task Manager and apart from the amount of memory usage (24.7MB for one and 28MB for the other) the other usage figures for CPU, Disk and Network were otherwise the same (zero).
John Marchington
-
Jul 8th, 2018, 11:12 PM
#5
Thread Starter
Lively Member
Re: Access Denied
Originally Posted by LaVolpe
DataMiser may be spot on. Definitely verify that. If the app is running, it can't be overwritten -- double check with Task Manager.
If the app isn't running when you are trying to recompile, does changing the exe name or destination folder allow the recompile to happen? Do you always run VB elevated?
Another slight possibility could be antivirus (AV) protecting the file. At my job, we have another layer of AV that can prevent recompiling the exe if the version number wasn't changed in project properties before recompiling attempted. Your problem sounds like it could be a scenario where another app may have your exe locked which makes me think of AV.
Thank you, LaVolpe, for your reply. Your first question is spot on. Changing the exe name DOES prevent the 'Access Denied' message from appearing. What is the significance of that? Your second question eludes me. What do you mean by running VB elevated? Some of my programs do utilise version numbers, where the major/minor/revision numbers change when I make code changes and I never see 'Access Denied' messages then.
For antivirus protection, I use Norton Internet Security so I guess, if the problem is AV related, there may be a setting somewhere in that which might overcome the problem.
John Marchington
-
Jul 9th, 2018, 06:51 AM
#6
Re: Access Denied
John, DataMiser was wanting you to check the running processes, not memory usage. Look for your app name in the process list when you get that error. If you see it there, your app is still running.
As for the questions you asked of me.
1. Relevance of changing the name negates any possibility of the folder location being at fault and/or permissions, for any reason.
2. As for elevated. VB should always be run elevated, i.e., as administrator. Simply including your account as admin isn't good enough. There are plenty of threads on this forum regarding problems associated with not running VB elevated on modern operating systems.
-
Jul 9th, 2018, 09:11 AM
#7
Re: Access Denied
You always had to run the VB6 IDE elevated on NT. What changed is how this is accomplished.
In olden times before Vista you got away with this by simply logging on as a member of Administrators or Power Users. People tended to do that willy-nilly and was unsafe, so UAC was created and Power Users eliminated to rein in unsafe behavior.
Win9x has no security at all so there was no issue back in those paleolithic times.
-
Jul 9th, 2018, 10:44 AM
#8
Hyperactive Member
Re: Access Denied
You can't compile the exe a second time because it is still running and windows cannot delete the file due to a file lock. Anyone can duplicate this:
- start a new project
- build Project1.exe
- run Project1.exe and leave it open
- try and build again = permission denied
JohnMarch needs to figure out why his program is not closing completely
-
Jul 9th, 2018, 06:30 PM
#9
Thread Starter
Lively Member
Re: Access Denied
Originally Posted by LaVolpe
John, DataMiser was wanting you to check the running processes, not memory usage. Look for your app name in the process list when you get that error. If you see it there, your app is still running.
As for the questions you asked of me.
1. Relevance of changing the name negates any possibility of the folder location being at fault and/or permissions, for any reason.
2. As for elevated. VB should always be run elevated, i.e., as administrator. Simply including your account as admin isn't good enough. There are plenty of threads on this forum regarding problems associated with not running VB elevated on modern operating systems.
Thank you again, LaVolpe.
Your comments are certainly interesting. What I can't understand is that, of those two similar programs I mentioned, it's generally the same one that produces the Access Denied error, yet there is actually very little difference between the two and I probably could have organised those differences in such a way so as to produce just one program. Furthermore, when the error occurs in just one of the programs, I've adopted the same approach to the recompiling process for both. If one of the programs is somehow still running at that time, I have absolutely no idea why.
As far as elevation is concerned, I assume I can right click the VB6.0 icon and select 'Properties',then choose the 'Security' tab from that. I have then tried setting both 'John's' and 'Administrator' options (clicking the Edit button first) but there are no 'Allow' boxes available at the bottom for either selection, only 'Deny' ones. Any suggestions always welcome.
John Marchington
-
Jul 9th, 2018, 09:15 PM
#10
Re: Access Denied
First, when the error occurs again, verify your app is not already running. In fact, you can probably try to replicate the problem by running your compiled exe, closing it normally as you would and try to recompile the project. If you get that error and one you are trying to recompile is still running, as shown by the task manager, then that is the problem. If that is the case, we can all offer possible reasons why that may be.
In the VB6 exe icon, right click and bring up the properties window. Under the Compatibility tab, you'll see "Run this program as administrator". Check that box, otherwise, always right click on VB6.exe and choose "run as administrator" from the popup menu
-
Jul 9th, 2018, 10:15 PM
#11
Thread Starter
Lively Member
Re: Access Denied
Originally Posted by LaVolpe
First, when the error occurs again, verify your app is not already running. In fact, you can probably try to replicate the problem by running your compiled exe, closing it normally as you would and try to recompile the project. If you get that error and one you are trying to recompile is still running, as shown by the task manager, then that is the problem. If that is the case, we can all offer possible reasons why that may be.
In the VB6 exe icon, right click and bring up the properties window. Under the Compatibility tab, you'll see "Run this program as administrator". Check that box, otherwise, always right click on VB6.exe and choose "run as administrator" from the popup menu
Thanks again. The "Run this program as administrator" option under "Compatibility" wasn't ticked so that is certainly a step in the right direction. I might leave it at that for the time being and see what happens when I next carry out program mods. Incidentally, I also noticed that Windows XP SP3 was chosen as the Compatibility Mode for the app. I can't for the life of me remember if I set it up that way initially - I guess I must have - but I certainly can't see that being an issue. After all, I think it was in the early 2000s when VB6.0 was replaced by VB.NET.
John Marchington
-
Jul 10th, 2018, 07:43 AM
#12
Re: Access Denied
> "I always Set the form (full form name) to equal Nothing after carrying out the Unload statement (using Me. I wonder of I should use the full name there too?). "
The Form's "name" is a "convenience", global variable that keeps track of the [first] instance of each Form.
"Unload Me" is fine, as is "Set Form1 = Nothing".
> " I have always been under the impression that using Nothing releases the form's memory usage. "
It certainly should.
Remember that any reference to the Form's global variable after you've Unload'ed the form will cause the Form to be reloaded into memory ...
Code:
Unload Form1
. . .
If Form1.Visible Then ' Reloads the form into memory.
. . .
End If
Timers that haven't stopped are another notorious cause of programs that simply don't want to die.
Regards, Phill W.
-
Jul 10th, 2018, 08:34 AM
#13
Re: Access Denied
Originally Posted by Phill.W
Timers that haven't stopped are another notorious cause of programs that simply don't want to die.
Can you give an example of this problem? I.e. an enabled timer force-loading it's just unloaded parent.
Mind you, that after reading such comments somewhere from the interwebs the beginners will start sprinkling Timer1.Enable = False in their projects just in case.
I think we've seen enough cargo-cult with ADO e.g. conn.Close : Set conn = Nothing when local variable conn is about to go out of scope.
cheers,
</wqw>
-
Jul 10th, 2018, 08:53 AM
#14
Re: Access Denied
Agreed; a Timer on its own will not cause this problem.
What are Timers often used for? Giving visual feedback about a process.
What does visual feedback involve? Using properties / controls on the Form.
What will that do if the Form's been unloaded? Automatically reload the form to make those properties / controls available.
Regards, Phill W.
-
Jul 10th, 2018, 09:55 AM
#15
Hyperactive Member
Re: Access Denied
Originally Posted by Phill.W
Agreed; a Timer on its own will not cause this problem.
What are Timers often used for? Giving visual feedback about a process.
What does visual feedback involve? Using properties / controls on the Form.
What will that do if the Form's been unloaded? Automatically reload the form to make those properties / controls available.
I've seen this before but it has always been accompanied by our old friend DoEvents() which lets the timer fire one more time.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|