Anyone?

Should I assume that 100 is only passing state variables to the Script and it's the language or hosting environment creating its own set of COM  objects based on iDispatch pointers?

Is Sage 100 BO just a custom object (OOP) implementation and the OLE layer is provided by PVXCOM.DLL? ProvideX native doesn't communicate with its objects internally via iDispatch and uses its internal ID references.

Let me simplify my request. When are iDispatch pointers created when using customizer VBScript based scripts?

This is encouraging but doesn't return an iDispatch pointer but the internal ProvideX object reference ID.

obus = COM::CBN(osession, "nGetObject", :CALL, "AR_Customer_bus")
PRINT obus, "\n" 

C:\ScriptBasic\examples>sbc showcust.sb
100063

C:\ScriptBasic\examples>

This is a list of the object handles from an OLE interface standpoint.

C:\ScriptBasic\examples>sbc showcust.sb
oscript: 8518836
osession: 8517324
oui: 8518404
obus: 100063

C:\ScriptBasic\examples>

The obus object handle was returned from the GetObject method call.

It sure would be nice to get a clear explanation of when OLE and the iDispatch interface comes into play. 

I tried to get the object handle from VBScript but no luck. Getting the TypeName of the object shows IPvxDispatch.

I'm beginning to wonder if under the covers VBScript is using ProvideX's internal object reference IDs and ScriptBasic is showing its iDispatch pointer reference.

I used the ScriptBasic DI (Display Typelib Interface) function on the osession variable ScriptBasic created.

Interface: IPvxDispatch
CLSID: {60503ABA-2D27-11D6-B249-00C04F50D575}
Version: 1.0
Get Instance() As String
Get CmdHandle() As Long
Get ScriptObject() As Object
Sub DropObject()
Sub FinalDropObject()

Here is the results of getting the object's properties.

C:\ScriptBasic\examples>sbc showcust.sb
ScriptBasic oscript: 10353684
osession instance: {7E027EA0-D44F-4642-8B9C-2C1FE34B9C4D}
osession CmdHandle: 100001
osession ScriptObject: 10353684
osession ScriptBasic: 10353828

C:\ScriptBasic\examples>

If I can pass the ScriptObject value from 100 to ScriptBasic on the DLL call of the NOMADS event, I might be able to use it without creating an OLE object in ScriptBasic.

Does anyone know if one is able to access COM/OLE automation objects from within a ProvideX based script?

I'm still trying to untangle when or if ProvideX object IDs become iDispatch pointers for OLE access, My initial thought was oScript was the parent object and all other objects were children of that object. WRONG

Quote:

There is a separate script object for each business object for which scripts have been tied to events usin User Defined Scripts. For example, SO_InvoiceDetail_bus has a script object associated with it, and SO_Invoice_bus (header object) has its own script object. Also, scripts run from the User Interface using a Customizer BT_Link script button have a separate script object.

I would like to pass to ScriptBasic 100 object iDispatch pointers that instantiated  by the Customer Maintenance for example. The mystery for me has been unless I CreateObject in ScriptBasic for a 100 object, an iDispatch pointer isn't created. A value of 100001 for SY_Session doesn't do me any good as a COM/OLE object reference to it.

It would be great if someone from the 100 development team could chime in and share with us the 100  iDispatch object story.

I have not been able to to create or access any 100 objects from within a script using ProvideX object ID references.I don't think Wscipt is running in the same process as the ProvideX instance that created it. So much for passing pointers as far as I can see, It would be great to see what a 'compiled' script looks like.

I'm making some progress. ProvideX instantiates the WSH script engine as an OLE object.  I'm still working on how ProvideX translates its object IDs in their current state to WSH.iDispatch handles.Once I figure that out I can create DLL calls to ScriptBasic on NOMADS events bypassing traditional scripting.

I'm learning a lot talking to myself.

IMPORT COM.sbi

oscript = COM::CREATE(:SET, "MSScriptControl.ScriptControl")
COM::DI(oscript)

COM::RELEASE oscript

This is the typelib for WSH.

Interface: IScriptControl
ProgID: MSScriptControl.ScriptControl.1
CLSID: {0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}
Get Language(pbstrLanguage As Object) As Hresult
Let Language(pbstrLanguage As String) As Hresult
Get Timeout(plMilleseconds As Object) As Hresult
Let Timeout(plMilleseconds As Long) As Hresult
Get AllowUI(pfAllowUI As Object) As Hresult
Let AllowUI(pfAllowUI As Boolean) As Hresult
Get UseSafeSubset(pfUseSafeSubset As Object) As Hresult
Let UseSafeSubset(pfUseSafeSubset As Boolean) As Hresult
Get CodeObject(ppdispObject As Object) As Hresult
Get Procedures(ppdispProcedures As Object) As Hresult
Function AddObject(Name As String, Object As Object, [AddMembers As Boolean = False]) As Hresult
Function Reset() As Hresult
Function AddCode(Code As String) As Hresult
Function Eval(Expression As String, pvarResult As Object) As Hresult
Function ExecuteStatement(Statement As String) As Hresult
Function Run(ProcedureName As String, Parameters As Object, pvarResult As Object) As Hresult

See this link for creating COM/OLE objects when using ProvideX.

DEF OBJECT Define Windows Object (pvxplus.com)

See this link for creating COM/OLE objects when using ProvideX.

DEF OBJECT Define Windows Object (pvxplus.com)

The problem isn't ProvideX creating an OLE iDispatch pointer with DEF OBJECT, it's converting an existing 100 object that has its properties already defined to an iDispatch version of it so I can pass that pointer to ScriptBasic in a DLL call. ProvideX and ScriptBasic are running in the same Windows process so passing pointers works great.

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.