Page 1 of 1
Weird Bug in Win7
Posted: Fri Sep 09, 2011 8:21 pm
by Rook Zimbabwe
I have an EXTREMELY weird bug in Win 7 to report... In my POS software which installs and is "supposed" to run out of its folder in PROGRAM FILES...
It can read databases and write to databases... but for some reason it will NOT add tax on any item! This happens even when run in compatibility mode for XP SP3 and 2000... I also not get a paranoid popup when I try to run from the OS... I suspect it is OS related but is there not some way to set a flag so WIN 7 allows it to run?
I already request admin level for VISTA on compilation!
Compiled in 4.6 RC 1... now attempting 4.5... NOPE won't do it
also 4.41 won't tax as well??? I know this is an OS bug but it pisses me off that PB and 7 aren't playing nice together! Anyone know how to FORCE all access in win 7 for a PB program?
Re: Weird Bug in Win7
Posted: Fri Sep 09, 2011 10:10 pm
by Michael Vogel
Have you tried to change the access rights for the folder where the database is located? Tried another directory, which isn't protected by Windows 7? What about the return codes of the file functions in PB, maybe you can log them for trouble shooting?
Re: Weird Bug in Win7
Posted: Fri Sep 09, 2011 10:26 pm
by Rook Zimbabwe
I was thinking that already and I THOUGHT I had changed it but I cannot seem to force permissions... Win7 updated today and, if anything, seems even MORE paranoid!
Funny thing... it refuses to access the database files from the
SAME FOLDER I have to figure out where it is getting its data because it is reading all database correctly and I did not put a path to access the databases intentionally so they should be in the same folder!
I can't locate it but I tell you that the search function is NOT helpful!

Re: Weird Bug in Win7
Posted: Fri Sep 09, 2011 11:15 pm
by Kuron
Rook Zimbabwe wrote:I was thinking that already and I THOUGHT I had changed it but I cannot seem to force permissions... Win7 updated today and, if anything, seems even MORE paranoid!
Funny thing... it refuses to access the database files from the
SAME FOLDER I have to figure out where it is getting its data because it is reading all database correctly and I did not put a path to access the databases intentionally so they should be in the same folder!
I can't locate it but I tell you that the search function is NOT helpful!

Because you do not have permission to access it where you are trying to, it is probably using your virtual store. I'm not being mean, but if you put the database in the proper place, you
shouldn't have the issue.
Re: Weird Bug in Win7
Posted: Fri Sep 09, 2011 11:28 pm
by Rook Zimbabwe
No matter HOW permissions are set everything in that folder is READ ONLY
yet when the program runs it shows the last entry... YET when I access the file from the directory it shows nothing has been added to it... there is no data!!!
I know 99% of this is windows! I had to upgrade to 7 to run an app for a short term job that still hasn't pais me and my XP box crashed bad!!! But this is impossible! I know programs use their directories in Program Files to read and write data... why can they and not us?
Opinions on where I should TRY to put the dang database would be helpful!
BTW it runs perfectly in the compiler... I have never claimed that before but tis true!
Re: Weird Bug in Win7
Posted: Fri Sep 09, 2011 11:40 pm
by Innesoft
Store the db in the user folder, with GetHomeDirectory() - you will have full read/write access and it's easy to find, otherwise as said before, win7 virtualizes your program folder in the virtual store, which means there are now 2 db files.. one in your program folder (which is ignored, hence no saving), and one in the virtual store which is saved/loaded on-the-fly by the os.
Just to reitterate, do not use the program folder to store user data on win7.
Re: Weird Bug in Win7
Posted: Sat Sep 10, 2011 12:16 am
by Kuron
Rook Zimbabwe wrote:No matter HOW permissions are set everything in that folder is READ ONLY
Those permissions have nothing to do with it

One simply does not have permission to write to a subdirectory of c:\program files anymore.
Rook Zimbabwe wrote:yet when the program runs it shows the last entry... YET when I access the file from the directory it shows nothing has been added to it... there is no data!!!
This is because the one you are editing and that shows the updates is in your virtual store, not the directory you think it is. If you try loading the database file from your virtual store, you should see that the data you added is there.
Rook Zimbabwe wrote:Opinions on where I should TRY to put the dang database would be helpful!
Many people think this is something new with Vista and 7, but it isn't. The proper location for these files has been unchanged since the active desktop update was released for Windows 95 in September 1997. The problem was that developers as a whole did not voluntarily store files where they were supposed to. Now Microsoft has clamped down on this and is making developers do what they should have been doing all along.
Given the age of Vista and 7, there are likely numerous examples floating around the forums on how to get the proper file locations for reading and writing with PB.
You could also take the easy way out and install everything to directory like c:\Ralphs POS\ This is NOT a recommended solution!
Re: Weird Bug in Win7
Posted: Sat Sep 10, 2011 12:27 am
by MachineCode
Kuron wrote:You could also take the easy way out and install everything to directory like c:\Ralphs POS\ This is NOT a recommended solution!
I'm not disagreeing with you, but why is this not recommended?
Re: Weird Bug in Win7
Posted: Sat Sep 10, 2011 12:55 am
by Kuron
MachineCode wrote:I'm not disagreeing with you, but why is this not recommended?
1. For your own use, this is fine, although you would probably want to do something like
c:\apps\Ralphs POS\
just to keep from cluttering your root drive.
2. Your EU may not be allowed to install programs to abnormal locations like this. Many businesses are very strict about where you are allowed to install programs. Heck, even before Vista, many businesses would not allow a program to be installed if it wrote to c:\program files. Many government agencies are like this.
3. Since this is not recommended by Microsoft, you have no guarantee this will be allowed in the future. Ie, your program may not be compatible with future versions of Windows.
4. IIRC, if you want to be able to use the "Compatible with Windows 7" logo your program must abide by all of the specified developer guidelines in order to be approved.
Personally, I am moving towards portable software and likely won't have to deal with this issue.
Re: Weird Bug in Win7
Posted: Sat Sep 10, 2011 1:23 am
by MachineCode
Kuron wrote:3. Since this is not recommended by Microsoft, you have no guarantee this will be allowed in the future. Ie, your program may not be compatible with future versions of Windows.
True, and here's my prediction: Microsoft will start charging a fee to install to "Program Files" while disabling installation to all other folders. Just watch. They're already stopping web downloads that aren't on their "white list" with Internet Explorer 9! True dictatorship.
Kuron wrote:Personally, I am moving towards portable software and likely won't have to deal with this issue.
So you just make your app available as a zip instead of Setup.exe? I might have to take that approach, too.
Re: Weird Bug in Win7
Posted: Sat Sep 10, 2011 2:45 am
by GoodNPlenty
I use SHGetSpecialFolderLocation_ to obtain the APPDATA directory which eliminates the program files directory read only issues on Vista and up..
From
http://msdn.microsoft.com/en-us/library ... s.85).aspx
#CSIDL_APPDATA The file system directory that serves as a common repository for application-specific data.
# CSIDL_LOCAL_APPDATA The file system directory that serves as a data repository for local (nonroaming) applications.
You need to consider whether your data is specific to that machine (# CSIDL_LOCAL_APPDATA), or to the user (#CSIDL_APPDATA).
Code: Select all
Procedure.s wpeSpecialFolderLocation(iSpecialFolder.i)
Protected SpecialFolderPath$ = Space(#MAX_PATH)
If SHGetSpecialFolderLocation_(0, iSpecialFolder, @*pidlItem.ITEMIDLIST) = #NOERROR
SHGetPathFromIDList_(@*pidlItem\mkid\cb, SpecialFolderPath$)
Else
SpecialFolderPath$ = #NULL$
EndIf
ProcedureReturn Trim(SpecialFolderPath$)
EndProcedure
Debug wpeSpecialFolderLocation(#CSIDL_LOCAL_APPDATA)
Debug wpeSpecialFolderLocation(#CSIDL_APPDATA)
Re: Weird Bug in Win7
Posted: Sat Sep 10, 2011 7:30 am
by jesperbrannmark
You all think of logic explainations....
I think it could only be either
1. Microsoft don't like TAX or VAT and decided to take it away from all its products
2. Microsoft releases their own Dynamics Ax a couple of days ago and decided to trash every other product to get rid of the competition.
and/or
3. Bill Gates is a satanist and he just want to bug you
(remember a couple of years ago when they just decided to removed "month" from a dll file I was using... with a normal windows update... that was funny... not)
Re: Weird Bug in Win7
Posted: Tue Sep 13, 2011 7:20 pm
by Rook Zimbabwe
It STILL refuses to do tax computations outside of the compiler... this is completely stupid and frustrating...
Can someone else doublecheck the DL?
http://www.bluemesapc.com/Downloads/SetuprPOS8-aio.zip
it should be all set up but you may need to move the access databases to the user folder!
Re: Weird Bug in Win7
Posted: Wed Sep 14, 2011 2:33 pm
by Zach
I have no idea how to use the program
Also.. your installing had the install path greyed out, don't know if that's intentional. It forced an install to ProgramFIles(x86)
It created program group, but only a shortcut for the Web Site, and for Uninstall. There is a shortcut for the EXE in the program folder though.
What EXE should I run? What steps should I take to try and reproduce your problem?
(The main BMrPOS8.exe says stuff about being unregistered, etc )
Re: Weird Bug in Win7
Posted: Wed Sep 14, 2011 2:43 pm
by Kuron
Ralph: You need to update your avatar, I think you have probably pulled all of your hair out by now
