2 mystery features.

[Dale Harris]

Here are two features that almost no one knows about and are not in the user's guide.

1. From the main POS menu it is possible to press [F4] to run a totally different program. When that other program restarts the POS program it will return you to the POS main menu, you will not have to restart the register and print an opening receipt.

2. When you exit the POS program by closing out the register the POS program can start another program.

Both of these features assume that the other programs are DOS software and that you can write a batch file.

1. From the main POS menu if you press [F4] the program will look in the disk folder for a file named NEXTFILE.DAT If the file is found the program will open it and read the file name of the program you want to run. Therefore the only thing that can be in the file is the other program's file name. POS will then close and run the other program.

When either you or the other program runs the POS.EXE program again it will bypass the startup procedure and return you to the main menu.

I use this feature for a "key blank finding" program. When I want to find a key I press [F4] on the register, look up the key, and then return to the main menu of the POS program.

2. When you close the register and reset the totals the program will look in the disk folder for a file named POS_NEXT.DAT If the file is found the program will open it and read the file name of the program you want to run. Therefore the only thing that can be in the file is the other program's file name. POS will then close and run the other program.

[ChrisKraus]

Nice, You should put these features in the manual, I think people would like these features.

- Chris

[Andrew]

If they were in the manual - they wouldn't be mystery features now would they?

[ChrisKraus]

I know, but I think people would really like these features. And if they are unknown, how are people going to use them. I also think that these options should be put into POSCONFIG and be labeled on the menus.

- Chris

[Andrew]

Chris,

You think too much.

[anabus_maximus]

And if he put it in the manual, he'd give the secret away to everyone who doesn't visit the forum. There should be an occasional bonus for the people who visit the forum regularly

[Guest]

Well, That Is True

[ChrisKraus]

Well, That Is True

I Posted This, Forgot To Login

[brucef2112]

Code: Select all

Dale says...2. When you close the register and reset the totals the program will look in the disk folder for a file named POS_NEXT.DAT If the file is found the program will open it and read the file name of the program you want to run. Therefore the only thing that can be in the file is the other program's file name. POS will then close and run the other program.

Dale,
Referencing 'Therefore the only thing that can be in the file is the other program's file name.'

1) Can the POS_NEXT.DAT include a fully qualified path and program.exe (Example: C:\OVERHERE\ISMY\Program.exe) or must it only contain the program.exe and therefor must be located in the DHPOS directory?

2) Does this work if a batch file is called instead of an exe?

3) Aside from the function of POS_NEXT.DAT to run only after register is closed and totals reset. Is there some other check, flag, or poke method to know when POS was closed for the end of day? Currently I've been running POS.exe from a batch file. After POS closes the batch continues by checking the journal file for the string "CLOSE CLOSE CLOSE CLOSE' to determine if the POS was temporarily closed during the day (it didn't find the string) or if it is the end of day close (because it found the string).
This method allows me to do 'A' if its a temp close during the day. Or 'B' if it is the end of day.

The obvious problem here is, if a new version of POS includes changes to the journal's format even by a single space my method breaks and I'd have to update the search string in the batch file.

Thanks a bunch!

[daleadmin]

brucef2112,

My initial response to your questions was to go try out options #1 and #2. Then a much better idea occured to me. You go try it out and report back here.

However here are some thoughts.

#1) You can probably run a program from a different directory, however since the active folder will not be changed any data files used by the program will have to be in your POS folder.

#2) If you can run a batch file then the batch file can first change the active folder and then call the program. Let us know how this works out.

#3) Ok, I am not really sure what you are trying to do with #3, or why you are trying to do it. But there is no check, flag, or poke when the program closes. There are several file updates from the program closing but these are mostly files with a secret file format so I cannot tell you how to look at them.

I have no reason, intention or plan of changing the "CLOSE CLOSE CLOSE CLOSE" line in the journal and it has not changed for years. But that does not mean that it will never change if some compelling need pops up, but change is doubtful.

[brucef2112]

Thanks Dale, I figure I'd ask *before* I hurt myself!

Without as much as a scratch, here's what I found:
1)A program in another directory will run OK by specifying the full 8dot3 path to the program. If the path is non 8dot3 it will work as long as you use the short DOS ~ path and file names. This works with either the NEXTFILE.DAT or the POS_NEXT.DAT. Example:
C:\OVERHERE\ISMY\Program.exe works fine.
C:\mylong~1\killap~1\coolpr~1.exe works fine also.
I also noted that the program name placed in the .DAT does not need to have the dot3 (.exe) extension.
'C:\OVERHERE\ISMY\Program' works fine without the .exe

2)It seems that you cannot run a batch file by placing its name in either DAT file. Using the F4 key (NEXTFILE.DAT) does nothing. With the POS_NEXT.DAT the POS closes down with an Error message (... error in line x in module pos2 blah blah blah) hitting the anykey dumps directly to DOS.
Also the same thing seems to be true of COM programs.

I also tried the batch file name placed in either .DAT without the .bat extension, however this does not work either. (hoping the implicit name would allow DOS to try COM, EXE, BAT etc., but it didn't work)

3) Knowing if the POS shutdown (close) was a temporary close during the day or at the End Of Day closeout does 2 things for me.
a: Helps keep an extra eye on the till and employees.
b: Does report house keeping at the end of the day after register is closed for the day.

If the employee closes the register (with Exit, No Print, No Erase) during the day I have the program write to a hidden file the time and date that the register was closed. I can then check the log to see how often this happens during a day. Its 1 more check of employees actions during the day.

If the program sees that the End Of Day closeout has occurred (because the 'close close close close' thing was in the journal) then the program finds the DHPOS auto reports for the day and moves them from the default register name directory given by the auto reports to an archive directory I choose and also change the file name to make it easy to find or ID them later. (example: DHPOS auto report name like 'CDmmddyy.txt' is saved as 'c:\my archive dir\registerNm reportNm yyyy-mm-dd.txt'

I have 4 different stores so the one batch program works to keep things consistent in the 4 stores and helps keep me happy!

I guess I'll stick with the 'close close close' thing to do the EOD check.

Thanks Dale,