I know this thread is a bit old but my ScriptBasic Customer Lookup ALE from BOI might help someone trying to do the same.

' COM - AR_Customer Lookup

IMPORT COM.sbi

oscript = COM::CREATE(:SET, "ProvideX.Script")
COM::CBN oScript, "Init", :CALL, "C:\\Sage\\Sage 100 Standard\\MAS90\\Home"
osession = COM::CBN(oscript, "NewObject", :SET, "SY_Session")
COM::CBN osession, "nSetUser", :CALL, "UserID", "Password"
COM::CBN osession, "nsetcompany", :CALL, "ABC"
COM::CBN osession, "nSetModule", :CALL, "A/R"
mdate = COM::CBN(osession, "sModuleDate", :GET)
COM::CBN osession, "nSetDate", :CALL, "A/R", mdate
COM::CBN osession, "nSetProgram", :CALL, COM::CBN(osession, "nLookupTask", :CALL, "AR_Customer_ui")
oui = COM::CBN(oscript, "NewObject", :SET, "AR_Customer_ui", osession)
COM::CBN oui, "nInvokeLookup", :CALL, "AR_Customer", retval

PRINT retval,"\n"

COM::CBN oui,"DropObject", :CALL
COM::RELEASE oui
COM::CBN osession, "DropObject", :CALL
COM::RELEASE osession
COM::RELEASE oscript

Note: FUNCTION / SUB () are optional if a value isn't returned. (see code above)

My understanding of the ProvideX COM emulation is the DropObject method drops the object at the ProvideX level, reduces the reference count for the object and does some cleanup. The RELEASE object frees the iDispatch COM interface to the object.

ScriptBasic and VBScript are variant based and variables don't need to be defined. (including arrays) ScriptBasic uses a traditional  BASIC syntax where VBScript is OOP centric. ScriptBasic still supports GOTO / GOSUB even within functions / subs.

Even though I maintain the ScriptBasic open source project, I'm a huge VB6 fan and use it on Windows 10 Pro to create my OCX forms and OLE callable classes which are able to callback to ScriptBasic functions and subs for further processing.

ScriptBasic has a single step debugger. With VBScript you keep trying stuff till it works. Another disadvantage of VBScript and ODBC is it uses ADO. (recordsets are OLE objects) which are slow and huge. ScriptBasic used the C ODBC API.

C:\ScriptBasic\examples>sbc cust_lookup.sb
01ABF

C:\ScriptBasic\examples>

Here is the same example in VBScript.

' VBScript - Customer Lookup

Set oScript = CreateObject ("ProvideX.Script")
oScript.Init "C:\Sage\Sage 100 Standard\MAS90\Home"
Set osession = oScript.NewObject("SY_Session")
osession.nSetUser "UserID", "Password"
osession.nSetCompany "ABC"
mdate = osession.sModuleDate
osession.nSetDate "A/R", mdate
osession.nSetProgram osession.nLookupTask("AR_Customer_ui")
Set oui = oScript.NewObject("AR_Customer_ui", osession)
custkey = ""
oui.nInvokeLookup "AR_Customer", custkey
WScript.Echo custkey

oui.DropObject
Set oui = Nothing
osession.DropObject
Set osession = Nothing
Set oScript = Nothing

C:\ScriptBasic\examples>cscript //Nologo cust_lookup.vbs
01ABF

C:\ScriptBasic\examples>

You would have to instantiate one of Sage's UI classes, as the lookups were never intended to be executed standalone.  But once you've instantiated a UI (such as what @JohnS  is doing,) using the customer Ui class as the launching point.  It's a bit of a hack to be honest, but in theory is should work.  Just remember that the users security is tied to the Ui task.

E

If you want to create a new customer from the command line without using the Sage Launcher the following works.

pvxwin32.exe ..\Launcher\Sota.ini ..\SOA\Startup.M4P -ARG DIRECT UION UserID Password ABC AR_CUSTOMER_UI 00JOHN;

00JOHN is the new customer key I wish to use.

This assumes that your current directory is ..\MAS90\Home.

This will open up Sales Order Entry without an order number predefined.

pvxwin32.exe ..\Launcher\Sota.ini ..\SOA\Startup.M4P -ARG DIRECT UION UserID Password ABC SO_SALESORDER_UI

This might be useful if one wants to use portions of 100's feature set as part of your own external enhancement.

Since Customizer can define mods by user / group a set of screens could be created to better integrate with an external application.

You can also open 100 UI screens from BOI. The magic happens when one can figure out how to embed (DLL call ?) scripting in the NOMADS definitions prior to the Process call.

' COM - AR_Customer Maintenance

IMPORT COM.sbi

oscript = COM::CREATE(:SET, "ProvideX.Script")
COM::CBN oScript, "Init", :CALL, "C:\\Sage\\Sage 100 Standard\\MAS90\\Home"
osession = COM::CBN(oscript, "NewObject", :SET, "SY_Session")
COM::CBN osession, "nSetUser", :CALL, "UserID", "Password"
COM::CBN osession, "nsetcompany", :CALL, "ABC"
COM::CBN osession, "nSetModule", :CALL, "A/R"
mdate = COM::CBN(osession, "sModuleDate", :GET)
COM::CBN osession, "nSetDate", :CALL, "A/R", mdate
COM::CBN osession, "nSetProgram", :CALL, COM::CBN(osession, "nLookupTask", :CALL, "AR_Customer_ui")
oui = COM::CBN(oscript, "NewObject", :SET, "AR_Customer_ui", osession)
COM::CBN oui, "nProcess", :CALL

COM::CBN oui,"DropObject", :CALL
COM::RELEASE oui
COM::CBN osession, "DropObject", :CALL
COM::RELEASE osession
COM::RELEASE oscript

Messaged removed.

Populating these event definitions within existing Sage screens, will likely break large portions of Sage driven logic, and is definitely not recommended.

Message removed.

John,

If you didn't know, jepritch is a lead Sage 100 programmer.  His advice is something you don't want to ignore.