From an internal script, you can usually use oScript.Evaluate("coBusiness") or oScript.Evaluate("_obj") to return a provideX object handle in the long data type.

Alternatively, in a internal script, you can use oBusObj.GetValue "_obj", ObjectHandle or oUIObj.GetValue "_obj", ObjectHandle

Thanks David!

I'll give your suggestions a try. It's a down hill ride once I can access 100 objects that use their internal references (100001 = SY_Session) to an iDispatch Windows pointer.

If the Customizer's version of the NOMADS .M4L file is the same as the original, using Customizer to create UDFs and additional UI controls might be a safer option with my ScriptBasic DLL scripting option. It also brings who sees what to the mix.

David,

These VBScript commands are being done after the Wscript Host has already been created by ProvideX as an object. I need to get the iDispatch pointers for internal objects ProvideX created before creating the Wscript Host object that runs your scripts in.

I'm simply trying to EXECUTE a DLL call from NOMADS events passing iDispatch pointers to created objects as a delimited string. Once the ScriptBasic script runs it  uses the passed iDispatch pointers to make OLE based calls to the 100 business module objects and data.

John

I don't think I can help you much more with that, if you look at the ProvideX documentation, it says object identifiers (what I've been referring to as object handles) are the 6 digit numbers that you get whether you are using a PVS script, VBScript, or using oScript.Execute to CALL or PERFORM a file containing ProvideX. 

Almost all object identifiers for Sage 100 classes that I have seen are 6 digits. 

Channels on the other hand, like for a file or *MEMORY* file appear to be 5 digits. 

NOMADs control identifiers appear to almost always start at 10001 and appear to be 5 digits.

I just need to understand the interface between ProvideX objects and when they become iDispatch pointers.

Would you happen to know where compiled scripts are stored?

Here is what object references look like from my test button on_focus NOMADS event. These same values are passed to the MS Wscript  object which user scripts run in. How Wscript translates ProvideX object handles into iDispatch pointers VBScript understands is still a mystery at the moment. I'm assuming the _OBJ is AR_Customer_ui.

After doing a DUMP of ProvideX's variables including objects nowhere did I see anything that resembles an iDispatch pointer. My guess at this point is Wscript Host is able to use ProvideX object references passing them on to the Wscript object create as arguments. I'm pretty sure at this point I'm not going to find what I'm looking for and need to find another approach.

ProvideX is able to create OLE iDispatch objects with DEF OBJECT. (how the MS Wscript Host is created)  I assume based on performance reasons 100 uses its internal 100001 - ... object references.

I can create a Customer Maintenance screen (or any other) externally via BOI as if it was created via the 100 Launcher. Doing it this way I have iDispatch references to objects and my NOMADS events can callback to ScriptBasic functions to process the customization scripting. Downside is you need to create your own launcher for your custom 100 screens, 

The ScriptBasic COM extension module already has a simplified C external function to callback to ScriptBasic's user functions and subs from ProvideX NOMADS events as a DLL call.

Question: I have been pondering how I can use BOI external 100 module generation without a Sage 100 Launcher. 

Answer: Use a BI application like DataSelf to pop a Customer Maintenance screen if a customer code / name is clicked. This would work for Sales Orders, Invoicing or anything else Sage 100 has to offer. 

External BOI scripting offers a lot of possibilities.

This has been a fun ride trying to find a way to use ScriptBasic as an internal scripting language. After giving up with trying to pass iDispatch pointers to objects I was ready to concede to using ScriptBasic for external BOI only. Then it hit me, why not use INVOKE WAIT to run ScriptBasic Windows to process the event. The Execute method of oScript can take you a long ways. A typical ScriptBasic script would execute in under 1/2 a second.

This is still in theory phase as I still need to see if I can access the ProvideX objects of the running module with a PVXCOM connection from ScriptBasic. I'm not overly optimistic until I see objects. 

Here is the code to run ScriptBasic.

This is the pvxarg.sb script

DECLARE SUB DLL ALIAS "dyc" LIB "dyc"                                                      
                                                                                           
pvx_ss = COMMAND()                                                                         
                                                                                           
DLL("ms,i,USER32.DLL,MessageBox,PZZL", 0, "ProvideX %SYS_SS = " & pvx_ss, "ScriptBasic", 0)

This version gets the %SYS_SS from ProvideX using PVXCOM.

DECLARE SUB DLL ALIAS "dyc" LIB "dyc"
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

pvx_ss = COM::CBN(oscript, "Evaluate", :CALL, "%SYS_SS")

PRINT DLL("ms,i,USER32.DLL,MessageBox,PZZL", 0, "ProvideX %SYS_SS = " & pvx_ss, "ScriptBasic", 0)

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