Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / DarkEDIT v1.56 compiling code that is not in the editor...huh?

Author
Message
pdq
17
Years of Service
User Offline
Joined: 20th Jul 2006
Location:
Posted: 13th Nov 2009 20:53
I have my students working with DB. I have run into an odd situation. Here is an example:

Two student are sharing the same computer as different users. They are saving their dba files into the "My Documents" folder. One of the students has saved his code, but when he compiles and runs the code, DB compiles and executes the other student's code. I do not know why DB is doing this. The student's code is clearly in the editor, the other code is not; yet, it is this other code that is executed. Anyone know what is going on?

Thanks.
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 13th Nov 2009 20:58
Some changes were made in V1.2 to get around differences between XP and that silly Vista permissions thingy.

So, out of interest, just before compiling, try emptying (delete) the contents of the C:\dbTemp folder. Save the source code again and compile.

If that results in the correct exe, repeat the process for the other user.

TDK

pdq
17
Years of Service
User Offline
Joined: 20th Jul 2006
Location:
Posted: 13th Nov 2009 21:34
Clearing the "dbTemp" folder seemed to solve the problem.
Is this going to have to be done everytime? I could only empty that folder if I signed on as an administrator, my students can't empty the folder since they do not have admin priv.

By the way, I am running Windows XP.
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 13th Nov 2009 21:45 Edited at: 13th Nov 2009 21:47
Ordinarily, the dbTemp folder would reside in the Documents and Settings folder belonging to the person logged onto Windows at the time.

In their infinite wisdom, when Vista was released, they decided to make this part of the system read-only so software (like DB) could not create temporary files/folders. Yet another reason to detest Vista - as if we needed any more...

When DBC V1.2 was released, in order for it to work correctly on Vista machines too, it started using C:\dbTemp - not realising that this would cause problems on multiple user machines.

If I were you, I'd create a small batch file which deletes all the files in the C:\dbTemp folder and give it an icon on the desktop of all those who log onto the machine. You may be able to use 'Run As Administrator' for the batch file.

Each user logs on then simply double-clicks the .BAT file icon before starting to use DB.

TDK

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Nov 2009 05:46
Quote: "If I were you, I'd create a small batch file which deletes all the files in the C:\dbTemp folder and give it an icon on the desktop of all those who log onto the machine. You may be able to use 'Run As Administrator' for the batch file."


Could the batch file be two fold - 1. clear out the dbtemp directory, and 2. launch DarkEdit ? That way the student only sees a launch icon for DarkEdit.

As another possibility, can the folder root\dbtemp (root could be c:\ or d:\ or whatever drive db.exe is installed on) have it's security changed so that all users have universal read/write access; db.exe can then overwrite the files with the current user's files instead of leaving the old files intact? I would guess that is the problem - another user can't overwrite the previous users files in the directory, that's why deleting them out of the directory before hand works. Can't one sign on as the administrator and change the folder properties/permissions themselves of dbTemp? That way everyone can read/write to it.

Enjoy your day.
pdq
17
Years of Service
User Offline
Joined: 20th Jul 2006
Location:
Posted: 14th Nov 2009 15:19
As TDK suggested, I will make a batch file. I'll have the batch file run at startup. That way when the new student logs on, the dbtemp will be emptied. I'll give that a shot and let you know how it works out when I get back to school on Monday.

I don't understand why TGC allowed such a bug like this to escape
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 14th Nov 2009 17:35
Quote: "I don't understand why TGC allowed such a bug like this to escape"


Actually, they didn't.

DBC is an obsolete product and no longer officially supported by TGC. The latest version we are now all using (V1.2) is a version modified with permission from TGC by Ron Erickson - a user and moderator on these forums.

The latest 'official' TGC version is V1.13.

If you don't need the new object lighting commands Ron added, you could use V1.13 instead which when using XP will not give you the problems you are experiencing.

TDK

pdq
17
Years of Service
User Offline
Joined: 20th Jul 2006
Location:
Posted: 16th Nov 2009 21:19
Back to School today and stuck with the same problem.

I placed a batch file to empty the dbTemp contents under "all users\start menu\programs\startup". It works, but only for me. If my students log on with their usernames it does not work. The batch file is executed, but the dbTemp contents are not deleted. This is frustrating, I had to visit each computer station to empty the contents manually before my students could begin their work.

You mentioned that v1.13 does not have this problem. Where can I get it and will it work with DarkEDIT?

THX
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 16th Nov 2009 22:16
@pdq
I don't mean to sound like a broken record but, isn't it possible just to change the permissions on the dbtemp folder to allow general read,write,execute access?

Enjoy your day.
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 16th Nov 2009 23:46
Latch:

I may be wrong, but I think that it's Windows not allowing a user to modify the contents of a directory (due to the multi-user policy), rather than the physical permissions the directory is set to.

I think you would probably have to use PolEdit.exe to change this, but as far as I'm concerned, to use that software you need a pointy hat, a long grey beard and a magic wand!

pdq:

The way I see it, if DBC V1.13 is not used, a batch file would work only if you run it before Windows XP kicks in.

I'd try placing the call for the batch file in the Autoexec.bat on the root of drive C: (create an empty text file of that name with Notepad if there isn't one already there).

I've not tried it, but it ought to work...

TDK

pdq
17
Years of Service
User Offline
Joined: 20th Jul 2006
Location:
Posted: 17th Nov 2009 01:42 Edited at: 17th Nov 2009 02:29
@TDK
Thanks. I'll give it a shot tomorrow.

***I just did some research and what I am reading is that XP does not use autoexec.bat other than for defining environment variables.

@Latch
I'll try that as well.

*** I can only see how this is done for sharing and modifying files between users, but not for a folder at the root directory.
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 17th Nov 2009 04:03 Edited at: 17th Nov 2009 04:04
Quote: "what I am reading is that XP does not use autoexec.bat other than for defining environment variables"


How about this...

Running a Batch File Before Logging on to Computer

TDK

pdq
17
Years of Service
User Offline
Joined: 20th Jul 2006
Location:
Posted: 17th Nov 2009 20:51
SUCCESS!!!

Thanks TDK, that solved the problem.

Login to post a reply

Server time is: 2024-04-23 22:04:12
Your offset time is: 2024-04-23 22:04:12