Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4401
Loc: New Jersey
|
OK - having had a few minutes to look at this, I'd start with pencil & paper and sketch out the flow of the key tasks.. (or - Notepad and keyboard). Something like:Declare vars
Define initial values
Describe the key tasks and identify UDFs to accomplish them
Identify Computer (@WKSTA)
Query database
is this computer listed?
If so, was the last update more than 6 months ago?
If NOT, exit - nothing to do
Need to perform an inventory
Clear/Init the NEWDATA array
Query for the following items and load the NEWDATA array with the results.
O/S Version
Hardware Platform
Installed Software
Use a UDF (such as WMYSysInfo) to query for this info. Extend the function to obtain other required parameters, such as....
For debugging, write the data to a .CSV file for viewing in Excel (CSV.kxf to convert between Array and CSV string)
Use DBLib.udf to write/update the database with the data in the NEWDATA Array
Log Errors/Results to C:\TEMP\INVENT.LOG (fMSG.kxf for timestamped logging)
I also use a Kix development application to create almost every Kix script. You can download the Kix Development Suite from our website and use the KGEN.BAT file to help generate and validate your code. I won't explain further as it's fully documented in the KGen User Guide and installation README file. It's free to download and use and includes our entire Kixtart function library.
KGen does make the following best practices easier to use -
Create a header file (scriptname.TXT) to identify the script, author, & version info. MAINTAIN THE VERSION INFO!! Use this file to set program options (SetOption() calls), declare any global vars, and any vars used by the main program.
Create one or more script files (##_scriptname_purpose.KXF) to define specific blocks of code. For example, I have a GUI script with two tab pages. I have the following files defined:
- scriptname.txt Initialization
- 01_FormMain.kxf Primary form definitions
- 02_FormTab1.kxf First tab form definitions
- 02_FormTab2.kxf Second tab form definitions
- 05_ProgMain.kxf The code that ties the app together
- 06_ProgTab1.kxf First tab function definitions
- 06_ProgTab2.kxf Second tab function definitions
- 10_ProgFunc.kxf app-specific functions common to the entire app
So - I have 8 files in my application development folder. This keeps all of the related code together. KGen will assemble these into a complete script, including any of the external UDFs they might reference. The completed script is several thousand lines of code, but none of the files I work on are more than a few hundred. Much easier to work with, and prevents all kinds of mistakes. If you don't use KGen, write a simple script to locate the .TXT and all .KXF files in your dev folder and combine them into a single .KIX script file. You'll need to deal with the external functions by placing them into your dev folder, but this gets messy as you use them in more and more projects.
Put the functions you download into a KixtartUDFs folder.
- NEVER modify these UDFs - treat them as if they were part of Kix!
- NEVER remove the UDF headers from your scripts - they provide important information when debugging!
- If a public function give you 80-90% of what you need, DO NOT EDIT THE FUNCTION! Create a copy of the file, give it a new file and function name, add the features you need and update the header to reflect the changes you made. Use the modified UDF in your code.
Use single quotes for Kix. Kix will understand both single and double quotes.. Other languages you might call, such as a Shell to the command processor, require double quotes. Using single quotes in Kix allows you to embed the double-quotes easily into the strings used to call Shell commands, SQL statements, etc.
Be consistent! If you look at any of my code, you can find similarities between each of the files. My preferences are:
- ALL CAPS for Macros and Global vars.
- MixedCase for local vars
- Form objects always start with a lower-case 3 character class identifier; and include some type of text to identify which form page/module it is associated with. This helps clarify the CLEAR button on the menu from the buttons on tabs 1 and 2, for example.
- Indent each loop 2 spaces (enough to be visible, not so much that you need a 70" monitor to see the entire line!) 
Use comments - explain what you did and why. This helps not only when others review your code, but when you have to come back in 6 months to implement a requested enhancement. My comment to code ratio in larger projects is typically 1.3:1 - 1.3 lines of comment for every line of code!
Use reasonable spacing and extra line breaks between logical blocks.
In summary, this won't directly fix the script you're using. You're starting with something that's 9+ years old, was not written following these best practices, but yet does what it was designed to do. If you want to use this in production, extract the best pieces of the original code and create a new, production-worthy app from scratch - something that will be reliable, self documented, and easy to maintain/troubleshoot/update.
Glenn
PS - here's my BASE.TXT file:; PROGRAM_NAME - DESCRIPTION
; Version #.# - AUTHOR - DATE
;
Break On
; Declare variables
; ======================================================================
Dim $Rc ; Return code catcher
Dim $ ; temp var
Global $DEBUG ; Debug flag
Global $VERSION ; version string
Global $MSG_LOG_, $ERR_LOG_ ; log filenames - used by fMsg()
; Set program options
; ======================================================================
$ = SetOption('Explicit', 'On')
$ = SetOption('WrapAtEOL', 'On')
$ = SetOption('NoVarsInStrings', 'On')
$ = SetOption('NoMacrosInStrings', 'On')
; Define values
; ======================================================================
$DEBUG = 0
$VERSION = '0.0'
; MAIN Code
; ======================================================================
_________________________
Actually I am a Rocket Scientist! 
|
