Author Topic: SBOCX  (Read 1455 times)

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #15 on: January 19, 2019, 05:19:23 PM »
Here is an example of running the same thread synchronously (RUN) multiple times with a reset before the final run.

Code: Script BASIC
  1. IMPORT sbt.sbi
  2.  
  3. sb_code = "a &= \"ABC\""
  4.  
  5. sb = SB_New()
  6. SB_Configure sb, "C:\\Windows\\SCRIBA.INI"
  7. SB_Loadstr sb, sb_code
  8. SB_Run sb, ""
  9. PRINT SB_GetVar(sb, "main::a"),"\n"
  10.  
  11. SB_Run sb, ""
  12. PRINT SB_GetVar(sb, "main::a"),"\n"
  13.  
  14. SB_ResetVars sb
  15. SB_Run sb, ""
  16. PRINT SB_GetVar(sb, "main::a"),"\n"
  17.  
  18. SB_Destroy sb
  19.  


C:\ScriptBASIC\examples>scriba t_run.sb
ABC
ABCABC
ABC

C:\ScriptBASIC\examples>



Offline Mike Lobanovsky

  • (re)TIRED
  • BASIC Developer
  • Posts: 265
Re: SBOCX
« Reply #16 on: January 20, 2019, 02:46:48 AM »
Quote
It assumes SB is the host and loading the COM as an extension.

Exactly. By design, SBCOM is the opposite of what you seem to be trying to implement.

Quote
I may use the threaded option for MODULE objects like IUP ...

Why would you ever need to run multiple IUP threads (i.e. IUP instances) in the first place?

Here's a typical example of a (CUI or GUI) application that may benefit from running multi-threaded.

Suppose we have an array of 600,000 reals and we need to know the total of their square roots. (I'm deliberately choosing the data types and arith operations that would take the interpreter rather long to execute, to be able to benchmark the example and see the difference)

A naive and brute force approach would be to For/Next through the entire array, take the square roots of its elements, and increment their total. But the time it would take the interpreter to complete the maths will probably be on the order of 60 seconds or more even if the loop is tight and wouldn't try to do anything else, e.g. print a [........] progress or [\|/-\|/-] spinner or pop up their GUI equivalents. Approx. 10 seconds after the loop starts, Windows is going to report your application as frozen and unresponsive, and kill it.

A wiser approach will be to let the main thread WaitForMultipleObjects() graciously (i.e. notifying Windows the thread is idling for a purpose), spawn 6 worker threads (assuming you have a 4 core Intel CPU) each to run the calc for 100,000 array elements and store the sum e.g. in element (0) of their respective array segments, and let the 8th thread print or roll the spinner.

When all the 6 worker threads are through, the main thread would wake up, kill the remaining 8th thread that's been running the spinner, and calc the final total iterating through the 6 intermediate accumulator elements at array indices (0), (100000), (200000), ..., (500000).

Et voila! You're going to reach your objective approx. 5 times faster than single-threaded (thread context switches take their toll so the time gain will always be lower than expected), and Windows isn't going to kill your app because using the WaitForMultipleObjects() system API has made it aware the application's been fully active all that time.

Unless you can draw up a similar analysis of your projected MT OCX use cases where your application(s) can benefit from running in a multi-threaded mode, you probably don't need MT at all.

Quote
Unless Mike has an idea how an OCX interface for SB can be created ...

If SB remains the host and the user control DLL is written in C/CPP with a flat API interface, then their interop should be implemented exactly as the one between SB and any other DLL, i.e. via DLLC. If the user control DLL is in fact a COM aware OCX and the program logic is built around COM objects, then the OCX should also have a flat API interface (like ProvideX) because SB cannot provide and accept COM objects directly as it doesn't have its own COM-compatible variant data management engine. The implementation should then resemble that of SBCOM with the means to fully and graciously handle COM variant creation/destruction added. (SBCOM uses a simplified scheme that precludes clean handling of variants because the server and client create their respective variants in different memory spaces. Currently its client and server COM variants cannot be safely managed (i.e. released/destroyed as needed) on the opposite side -- only on the side where they've been created)

Until you sort out the design and logical structure of the interop you want to implement, Mike won't have the slightest idea of how to implement such an interface and whether OCXes are needed for it at all, in the first place.
« Last Edit: January 20, 2019, 03:16:52 AM by Mike Lobanovsky »
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #17 on: January 20, 2019, 06:12:03 AM »
Thanks Mike for your feedback on how this should unfold.

I'm going to take the Online Dictionary IUP example and rework it into an object paradyme with thread modules. I think the OCX wrapper should come last.
« Last Edit: January 20, 2019, 08:13:17 AM by John »

Offline Mike Lobanovsky

  • (re)TIRED
  • BASIC Developer
  • Posts: 265
Re: SBOCX
« Reply #18 on: January 20, 2019, 08:59:56 AM »
I think the OCX wrapper should come last.

That's exactly what I was trying to convey. Formulate the task, build a test bench, and finally optimize the design. :)
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #19 on: January 25, 2019, 06:34:04 PM »
I'm working on getting the VB6 IDE and VS2012 running on Windows 10 so I can support Dave's COM extension module on my new laptop. Putting Windows 7 behind me is the goal.

Step 1. VB6 install - Complete

I'm amazed how fast it runs.
« Last Edit: January 26, 2019, 12:52:06 AM by John »

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #20 on: January 26, 2019, 12:07:43 AM »
Mike,

I think I figured out how to create a VB6 OCX that can call Script BASIC as a DLL. I'll try to create a proof of concept after I get my Win10 laptop setup.

Offline Mike Lobanovsky

  • (re)TIRED
  • BASIC Developer
  • Posts: 265
Re: SBOCX
« Reply #21 on: January 26, 2019, 01:09:35 AM »
... a VB6 OCX that can call Script BASIC as a DLL.

If the SB DLL is somewhere in the system known path and has a flat stdcall compatible interface then your VB6 program code should include SB function declarations in a generic form of

Public Declare Function Foo Lib "Bar" (ByVal Baz As Long) As Long

and just call these functions as necessary throughout the code. VB6 will take care of the rest including loading and mapping the SB DLL in the VB6 process memory.

OTOH if there's only one flat API function there, something like sbRetVals _stdcall Exec(char* code) or similar (I'm too lazy to look it up in the docs) then the VB6 code should include this function declaration, e.g.

Public Declare Function Exec Lib "libscriba" (ByRef code As String) As sbRetVals (this might be an SB success/failure ret val enum, whatever)

and call it with the SB code pieces in the form of strings for the SB Exec() function to execute.

Still alternatively, if libscriba contains only cdecl APIs then you should additionally create a corresponding stdcall proxy DLL that the VB6 OCX should call instead. Then again, all forms of calls to the proxy DLL API should first be declared in the VB6 code.
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #22 on: January 26, 2019, 01:15:44 AM »
Thanks Mike for the help and suggestions. Before I create the OCX part I need to create a SB.DLL that has both the embedded and extension API headers and created as a DLL. (libscriba +)

The SBT DLL would work if it were a standard DLL and not a SB extension module.

I may have to bite my tongue with that last statement. It looks like the functions needed are also exported as standard C API calls like If I were calling libscriba from another language. I haven't tried calling a SB DLL/shared object from anything other than SB. Should be interesting. BTW this same opportunity should be available with the Windows version ot SBT.  That would be very cool if SBT could be used as an extension module and OCX interface.

Note: -g, --extern-only      Display only external symbols

Code: Bash
  1. jrs@jrs-laptop:~/sb/modules$ nm -g sbt.so
  2. 0000000000002450 T bootmodu
  3. 0000000000006120 D __bss_start
  4.                  U __ctype_b_loc
  5. 0000000000006120 D _edata
  6. 0000000000006120 D _end
  7. 0000000000002470 T finimodu
  8.                  U free
  9. 0000000000002330 T ltrim
  10.                  U malloc
  11.                  U memcpy
  12.                  U memmove
  13. 0000000000002390 T rtrim
  14. 0000000000002a70 T SB_CallSub
  15. 0000000000002b30 T SB_CallSubArgs
  16. 00000000000024e0 T SB_Configure
  17. 0000000000002a10 T SB_Destroy
  18. 0000000000002ee0 T SB_GetVar
  19. 0000000000002590 T SB_Load
  20. 0000000000002640 T SB_LoadStr
  21. 0000000000003660 T SB_msSleep
  22. 0000000000002480 T SB_New
  23. 00000000000027d0 T SB_NoRun
  24. 00000000000035f0 T SB_ResetVars
  25. 0000000000002710 T SB_Run
  26. 00000000000032d0 T SB_SetDbl
  27. 0000000000003140 T SB_SetInt
  28. 0000000000003460 T SB_SetStr
  29. 0000000000003070 T SB_SetUndef
  30. 00000000000029f0 T SB_ThreadEnd
  31. 0000000000002870 T SB_ThreadStart
  32.                  U scriba_Call
  33.                  U scriba_CallArgEx
  34.                  U scriba_destroy
  35.                  U scriba_GetVariable
  36.                  U scriba_GetVariableType
  37.                  U scriba_LoadConfiguration
  38.                  U scriba_LoadProgramString
  39.                  U scriba_LoadSourceProgram
  40.                  U scriba_LookupFunctionByName
  41.                  U scriba_LookupVariableByName
  42.                  U scriba_new
  43.                  U scriba_NewSbDouble
  44.                  U scriba_NewSbLong
  45.                  U scriba_NewSbString
  46.                  U scriba_NewSbUndef
  47.                  U scriba_NoRun
  48.                  U scriba_ResetVariables
  49.                  U scriba_Run
  50.                  U scriba_SetFileName
  51.                  U scriba_SetProcessSbObject
  52.                  U scriba_SetVariable
  53.                  U __stack_chk_fail
  54.                  U strcpy
  55.                  U __strcpy_chk
  56.                  U strlen
  57.                  U thread_CreateThread
  58.                  U thread_ExitThread
  59. 0000000000002420 T trim
  60.                  U usleep
  61. 0000000000002440 T versmodu
  62. jrs@jrs-laptop:~/sb/modules$
  63.  

 
« Last Edit: January 26, 2019, 02:13:49 AM by John »

Offline Mike Lobanovsky

  • (re)TIRED
  • BASIC Developer
  • Posts: 265
Re: SBOCX
« Reply #23 on: January 26, 2019, 04:11:23 AM »
First get simple VB6 exe code to work directly with raw libscriba. That'll be the starting point. Then let the problems be resolved as they arise.
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #24 on: January 26, 2019, 09:07:52 AM »
Libscriba only has the extension API. Calling SBT from something other than SB is the goal. SBT is scriba in a DLL.
« Last Edit: January 26, 2019, 09:14:57 AM by John »

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #25 on: January 26, 2019, 10:36:19 AM »
The only thing that is an issue with VB6 on Win10 is control resizing using the visual resizing grips. Using Shift Arrow keys is my workaround. I would be interested if someone has found a fix for this issue. On a positive note, mouse wheel scrolling works in this release of Win10 without any special drivers.

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #26 on: January 26, 2019, 08:22:28 PM »
I was able to resolve the issue with the control resize flashing and non-responsive. The trick was to use Windows Vista Service Pack 2 compatibility mode for VB6.EXE. Works like normal again.  8)

VB6 is still one of the best and easy to use GUI IDE environments still today. Krool's Common Controls Replacement OCX brings VB6 to current UI standards in both the IDE and runtime. The 'side-by-side' feature eliminates the need to register the CCR OCX.

The other benefit of using VB6 is the vast amount of code available ready to use in your project.

VB6 Resources and Documentation - Microsoft

« Last Edit: January 27, 2019, 07:06:11 PM by John »

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #27 on: January 27, 2019, 01:24:27 PM »
Step 2. VS2008Pro Install - Complete

I can now put my Windows 7 development behind me as my toolbox now runs on Windows 10.

Here is the COM extension module compiled by VS2008 on Windows 10.


1>------ Build started: Project: COM, Configuration: Debug Win32 ------
1>Compiling...
1>typeinfo.cpp
1>c:\scriptbasic_control-master\engine\com_extension_dll\typeinfo.cpp(259) : warning C4018: '<' : signed/unsigned mismatch
1>c:\scriptbasic_control-master\engine\com_extension_dll\typeinfo.cpp(394) : warning C4018: '<' : signed/unsigned mismatch
1>c:\scriptbasic_control-master\engine\com_extension_dll\typeinfo.cpp(410) : warning C4018: '<' : signed/unsigned mismatch
1>c:\scriptbasic_control-master\engine\com_extension_dll\typeinfo.cpp(318) : warning C4101: 'buf' : unreferenced local variable
1>c:\scriptbasic_control-master\engine\com_extension_dll\typeinfo.cpp(493) : warning C4102: 'error' : unreferenced label
1>c:\scriptbasic_control-master\engine\com_extension_dll\typeinfo.cpp(476) : warning C4101: 'hr' : unreferenced local variable
1>COM.cpp
1>c:\scriptbasic_control-master\engine\sb\include\global.h(13) : warning C4005: '_CRT_SECURE_NO_WARNINGS' : macro redefinition
1>        command-line arguments :  see previous definition of '_CRT_SECURE_NO_WARNINGS'
1>c:\scriptbasic_control-master\engine\sb\include\md5.h(16) : warning C4005: 'PROTO_LIST' : macro redefinition
1>        c:\scriptbasic_control-master\engine\sb\include\global.h(33) : see previous definition of 'PROTO_LIST'
1>c:\scriptbasic_control-master\engine\com_extension_dll\com.cpp(71) : warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details.
1>        c:\program files (x86)\microsoft visual studio 9.0\vc\include\string.h(207) : see declaration of 'strdup'
1>c:\scriptbasic_control-master\engine\com_extension_dll\com.cpp(107) : warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details.
1>        c:\program files (x86)\microsoft visual studio 9.0\vc\include\string.h(207) : see declaration of 'strdup'
1>Generating Code...
1>Compiling resources...
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>Linking...
1>   Creating library ./COM.lib and object ./COM.exp
1>Performing Post-Build Event...
1>        1 file(s) copied.
1>Build log was saved at "file://C:\ScriptBasic_Control-master\engine\COM_Extension_DLL\Debug\BuildLog.htm"
1>COM - 0 error(s), 10 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========




« Last Edit: January 27, 2019, 08:54:55 PM by John »

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #28 on: January 28, 2019, 11:23:31 PM »
It looks like I might have been wrong about libscriba.dll not having the exported functions needed to emulate SBT functionality. I'm going to try using it directly from VB6.

Dave's VB6 IDE/Debugger source should be a helpful guide with calling SB functions.

In reality, all I need to do is create an instance of SB from VB6 which is about a 5 calls to libscriba or SBT.dll (if I csan get that working) and that instance of SB with the SBT extension module does all the heavy lifting.



« Last Edit: January 28, 2019, 11:50:50 PM by John »

Offline John

  • Forum Support / SB Dev
  • Posts: 2683
    • ScriptBasic Open Source Project
Re: SBOCX
« Reply #29 on: January 29, 2019, 09:34:16 AM »
It seems I'm having the same luck with this as the last time I tried to suggest VB6 as a development environment. I'm going to make it my pet project on Windows and everyone else can play Windows API and maybe create another BASIC.