Page 3 of 3

Posted: Mon Sep 12, 2011 6:49 pm
by GomezL
Silly question isn't ENV$("VARIABLE") THE SAME AS "S_"?

Posted: Mon Sep 12, 2011 7:25 pm
by gtisdale
I don't know. Probably, but some times I'm finding that what I thought was the ENV$(variable$) isn't turning out that way. For example query ENV$("TEMP") on the client and on the server when you are running both on the same machine.

I'm just keeping my options open.

Posted: Sat Sep 24, 2011 6:53 am
by gtisdale
Is there a way to tell, once BR is running in 4.3+, whether the user is logged on using client server or combined (just executing the SERVER.exe)?

The reason I am looking for this clue is I want to be able to adjust certain functions and shell calls to do one thing if the client server is active and another if SERVER alone is running.

For example,
a) if a client is logged on over the internet, and there is no drive sharing, then loading a document that resides on the server into Word involves copying the document to a local location, finding out where Word is installed on the local machine, executing a shell call to load Word with the specified file active, making changes to the files, possibly printing the fifle, resaving the file, and finally copying it back to the server. This means that BR can not continue until this process has completed.
b) if the user is logged into BR through BRSERVER (or there is a drive share) then the process can be to search for the location of Word, load the file directly from the server, process it and resave it directly to the server. In this case BR can continue while the Word file is being processed.

In my case I want to set up client server with no drive shares, so I want to be able to omit the "-c" in certain shell calls. If I can tell whether client server is active then I can set a variable to blank or "-c" and accomplish my goal. I could do this by setting an ENV$ variable in the WBCONFIG.sys file, but that is two steps and not friendly with the goal of FNSNAP to be plug and play.

Any suggestions?

Thanks

FNGeorge

Posted: Sat Sep 24, 2011 11:38 am
by gordon
We added a number of ENV$ interrogation keywords in 4.3
Some of these are:

Code: Select all

ENV$("CLIENT_PLATFORM") is "WINDOWS"
ENV$("CLIENT_PLATFORM.BR_BUILD_TYPE") is "DebugEfence"
ENV$("CLIENT_PLATFORM.BR_BUILD_DATE") is "2011-05-12"
ENV$("CLIENT_PLATFORM.BR_BITS") is "32"
ENV$("CLIENT_PLATFORM.OS_BITS") is "64"
ENV$("CLIENT_PLATFORM.OS_VERSION_NAME") is "Windows 7"
ENV$("CLIENT_PLATFORM.OS_VERSION_NUMBER") is "6.1"
ENV$("SERVER_PLATFORM") is "LINUX"
ENV$("SERVER_PLATFORM.BR_BUILD_TYPE") is "DebugEfence"
ENV$("SERVER_PLATFORM.BR_BUILD_DATE") is "2011-05-13"
ENV$("SERVER_PLATFORM.BR_BITS") is "64"
ENV$("SERVER_PLATFORM.OS_BITS") is ""
ENV$("SERVER_PLATFORM.OS_VERSION_NAME") is "#36-Ubuntu SMP Thu Jun 3 20:38:33 UTC 2010"
ENV$("SERVER_PLATFORM.OS_VERSION_NUMBER") is "2.6.32-22-server"
Unfortunately we missed BR_MODEL. So we will add that.

For now George, I suggest that you create your own BR_MODEL env$ setting with the SETENV configuration statement and test for either "CLIENT/SERVER" or "COMBINED".

Posted: Sat Sep 24, 2011 2:43 pm
by gtisdale
Thank you Gordon.

Posted: Sun Sep 25, 2011 5:31 am
by GomezL
If you know what drive is supposed to exist for the user, you can check at startup:

If exists("@::F:\APP_PATH\") THEN LET SETENV$("APP_PATH_LOCAL_DRIVE")="F:\APP_PATH"

Or some other similar flag.

Then your function only needs to query the environment variable.

As I think about it, you can set the environment variable to point to the clients path in your WBCONFIG.SYS file, and then on startup, after confirming that the provided drive path exists, you can add "@::" if the drive path is "Local Only" (Mapped differently than the server"), or change it to another path if the mapping is not available on the server.


Examples:

F:\App_Path Client & Vitual Server Path both use the same path
@::X:\App_Path Client uses "X:" to point the the "F:\App_Path" folder.
@::C:\Users\siul\AppData\Local Client uses a completely different path than the server.

Printer Selection

Posted: Sun Oct 02, 2011 11:59 am
by gtisdale
Sometimes the WIN:/SELECT option is not available when selecting a printer, like in Linux or perhaps MAC environments, or in certain cases in Client Server. The PRINTER_LIST function can, however, get a printer name to use.,

I put together a library function that I think solves this problem and would like feed back. Attached is a program that includes the function and runs it as a test. Yes, it does require FNSNAP.dll in VOL002 to make it work (my intention is to have this another function in FNSNAP).

The first few lines of the attached program are the test. The optional parameter for the function is the item to seach for in the PRINTER_LIST array. Please try it and let me know if it works or fails for you in your environment.

Thanks for the help.

FNGeorge

Posted: Sun Oct 02, 2011 12:03 pm
by bluesfannoz
Not sure what you mean by not being available? It works perfectly fine in the MAC environment. Linux you have to use a Windows or Mac client and since win:/select is client only, its always going to be there. So I guess I am confused by when its not going to be available?

I will try to test your program though when I am at the office.

Posted: Sun Oct 02, 2011 12:30 pm
by bluesfannoz
Because I didn't like the Printer Selection being tied to when I opened and closed the printer job. I built myself a printer selection program several years ago. I have not yet implemented it, because we have not fully moved to WIN: printing.

I have attached what I put together. Its rather crude. It was somewhat designed to emulate the Windows printer selection box and give you options for printing your report different ways.

Posted: Mon Oct 03, 2011 8:06 am
by gordon
I welcome the mutual evaluation of a printer selection function.

I have recently updated the wiki concerning the SELECT clause of the PRINTER TYPE statement. This will assist in utilizing PREVIEW:/SELECT generically because it puts light on how the process works internally.

HOWEVER, the big advantage of developing a routine for doing this is it opens the door to redirecting reports to PDF, Excel and HTML. This is something CLS has been doing for years and is supported by PRINTER.CLS.

There are also times when certain reports need to be restricted to certain printers for security purposes.