All BASIC

Message Boards => Scripting Languages => Topic started by: John on January 16, 2019, 09:37:53 PM

Title: SBOCX
Post by: John on January 16, 2019, 09:37:53 PM
Mike,

If I load an OCX with a SB script, can another OLE process connect to the OCX and have it callback to a SB function. Nothing visuall, just a OLE SB interface.

I don't see this much different than Sage's PVXCOM OLE interface to the language.

The cool part is SB could run out of a DLL. (libscriba) MODULEs could be objects created as SBT threads.
Title: Re: SBOCX
Post by: Mike Lobanovsky on January 17, 2019, 02:24:47 AM
For all intents and purposes, an OCX is just a DLL which means its single disk copy can be reused concurrently by an infinite number of memory images in an infinite number of processes, each image for its own purpose. However that also means that interprocess communication restrictions apply.

A COM-aware DLL (OCX) is an inproc (in-process) server, and though it is theoretically possible to set up a common "shared" memory store for numeric values through the DLL, the trick won't work for handles or pointers to objects, UDTs, strings, functions, etc. because each process has its own address space whose pointer values are meaningless for another concurrent process. Thus generally speaking, you can't use the DLL for interprocess communication.

OTOH if a call to an SB callback is programmed within the OCX as a means to implement some of its particular functionalities, then the scheme will most likely work if SB is compiled as a DLL as well. It will then be mapped into the memory space of the process that's calling the "parent" OCX.

(Why not use an SB specific thread for such a question, John?)
Title: Re: SBOCX
Post by: John on January 17, 2019, 09:08:05 AM
Thanks Mike!

I'll try putting a proof of concept together and get a copy to you. I think the idea has a lot of merit.

MT will be the shared memory means of communication. SB as a COM OLE OCX running in a thread safe model could make the language more attractive under Windows 32 bit.

I will clean  up this thread today.
Title: Re: SBOCX
Post by: John on January 17, 2019, 07:23:20 PM
For some reason my SBT extension module is segment faulting under Ubuntu 18.10. I rebuilt the extension module (no errors) and it still does the same.  :-[

I'll give it a try under Windows 7 which is where is going to run anyway. I confused why my Linux version of SBT no long works.
Title: Re: SBOCX
Post by: John on January 17, 2019, 07:48:54 PM
Works great under Windows.

This is a quick proof of concept for the SBOCX control. Script BASIC would be loaded by the OCX and the worker script creates threads for object MODULEs. The main SB process can call functions/subs (METHODS) and access global variables not defined with the LOCAL keyword. (PROPERTIES)


This example is like doing a RUN in other interpretive BASIC languages. With SB you can load the script without running it, run it multiple times and clearing or leaving the variables as is with the next run command.

Code: Script BASIC
  1. ' SBOCX Proof of Concept
  2.  
  3. IMPORT sbt.sbi
  4.  
  5. sb_code = """
  6. MODULE JRS
  7. FUNCTION prtvars(a, b, c)
  8.  PRINT a,"\\n"
  9.  PRINT FORMAT("%g\\n", b)
  10.  PRINT c,"\\n"
  11.  prtvars = "Function Return"
  12. END FUNCTION
  13.  
  14. a = 0
  15. b = 0
  16. c = ""
  17.  
  18. END MODULE
  19. """
  20.  
  21. sb = SB_New()
  22. SB_Configure sb, "C:/Windows/SCRIBA.INI"
  23. SB_Loadstr sb, sb_code
  24. SB_NoRun sb
  25. ' Call function before running script
  26. funcrtn = SB_CallSubArgs(sb,"jrs::prtvars", 123, 1.23, "One, Two, Three")
  27. PRINT funcrtn,"\n"
  28. ' Run script initializing globals
  29. SB_Run sb, ""
  30. ' Assign variables values
  31. SB_SetInt sb, "jrs::a", 321
  32. SB_SetDbl sb, "jrs::b", 32.1
  33. SB_SetStr sb, "jrs::c", "Three,Two,One"
  34. ' Call function again with variables assigned in the previous step
  35. SB_CallSubArgs sb, "jrs::prtvars", _
  36.           SB_GetVar(sb, "jrs::a"), _
  37.           SB_GetVar(sb, "jrs::b"), _
  38.           SB_GetVar(sb, "jrs::c")
  39. SB_Destroy sb
  40.  


C:\ScriptBASIC\examples>scriba sbt_module.sb
123
1.23
One, Two, Three
Function Return
321
32.1
Three,Two,One

C:\ScriptBASIC\examples>



This example is running the script as a self running thread. The main SB process can still make calls and return global variables like the run example above. The MT extension module can be used to post status info to R/W lockable shared memory space.

Code: Script BASIC
  1. IMPORT sbt.sbi
  2.  
  3. sb = SB_ThreadStart("tcall.sb",undef,"C:\\Windows\\SCRIBA.INI")
  4. SB_SetInt sb, "main::a", 123
  5. SB_SetDbl sb, "main::b", 1.23
  6. SB_SetStr sb, "main::c", "One, Two, Three"
  7. funcrtn = SB_CallSubArgs(sb, "main::prtvars", _
  8.           SB_GetVar(sb, "main::a"), _
  9.           SB_GetVar(sb, "main::b"), _
  10.           SB_GetVar(sb, "main::c"))      
  11. PRINT funcrtn,"\n"
  12. SB_Destroy sb
  13.  

Code: Script BASIC
  1. FUNCTION prtvars(a, b, c)    
  2.   PRINT a,"\n"              
  3.   PRINT FORMAT("%g\n", b)  
  4.   PRINT c,"\n"              
  5.   prtvars = "Function Return"
  6. END FUNCTION                
  7.                              
  8. a = 0                        
  9. b = 0                        
  10. c = ""                      
  11.  


C:\ScriptBASIC\examples>scriba t_thread.sb
123
1.23
One, Two, Three
Function Return

C:\ScriptBASIC\examples>


Title: Re: SBOCX
Post by: John on January 17, 2019, 10:59:57 PM
This example shows that SB is truly running in a theaded model.

Code: Script BASIC
  1. ' SBT Main
  2.  
  3. IMPORT sbt.sbi
  4.  
  5. SB_ThreadStart("sbt_thread.sb", "1","C:/Windows/SCRIBA.INI")
  6. SB_ThreadStart("sbt_thread.sb", "2","C:/Windows/SCRIBA.INI")
  7. SB_ThreadStart("sbt_thread.sb", "3","C:/Windows/SCRIBA.INI")
  8.  
  9. FOR x = 1 TO 10
  10.   PRINT "Main: ",x,"\n"
  11.   sb_msSleep(10)
  12. NEXT
  13.  
  14. SLEEP(2)
  15.  

Code: Script BASIC
  1. ' SBT Thread
  2.  
  3. IMPORT sbt.sbi
  4.  
  5. tnum = COMMAND()
  6.  
  7. FOR x = 1 TO 10
  8.   PRINT "T-" & tnum," : ",x,"\n"
  9.   SB_msSleep(10)
  10. NEXT
  11.  
  12. SB_ThreadEnd
  13.  


C:\ScriptBASIC\examples>scriba sbt_main.sb
T-1 : 1
T-2 : 1
T-1 : 2
T-2 : 2
T-3 : 1
Main: 1
T-2 : 3
T-1 : 3
T-3 : 2
Main: 2
T-1 : 4
T-2 : 4
T-3 : 3
Main: 3
T-2 : 5
T-1 : 5
T-3 : 4
Main: 4
T-1 : 6
T-2 : 6
T-3 : 5
Main: 5
T-2 : 7
T-1 : 7
T-3 : 6
Main: 6
T-1 : 8
T-2 : 8
T-3 : 7
Main: 7
T-2 : 9
T-1 : 9
T-3 : 8
Main: 8
T-1 : 10
T-3 : 9
T-2 : 10
Main: 9
T-3 : 10
Main: 10

C:\ScriptBASIC\examples>


Title: Re: SBOCX
Post by: Mike Lobanovsky on January 18, 2019, 03:22:23 AM
Yes, the last printout definitely looks like a few unsync'ed  threads randomly overtaking ownership of the console buffer to print their respective output in an out-of-order fashion.
Title: Re: SBOCX
Post by: John on January 18, 2019, 09:19:59 AM
Is that your translation of WOW?

I'm working on creating the OCX part now.

If anyone is interested and would like to follow along, the Windows 32 bit Script BASIC Inno install has the SBT extension module and a couple examples to work with.

When I'm done, SB can run in the console, as a true Windows app or as as a COM/OLE object interface callable by COM/OLE automation compliant languages and tools. Along with its original design of being an embeddable scripting engine.
Title: Re: SBOCX
Post by: Mike Lobanovsky on January 18, 2019, 03:16:04 PM
Is that your translation of WOW?

No, that's just a statement of fact that the intermittent printout looks pretty much like the For/Next loops would look printing from known genuine threads that haven't been synchronized with mutexes, semaphores, or critical sections. I used to have a similar sample script to demonstrate FBSL Dynamic C JIT compiler's multithreading capabilities.
Title: Re: SBOCX
Post by: John on January 18, 2019, 03:21:29 PM
You're forgiven.  :)

SBT has been a goal of mine with SB since the beginning. I knew it could be done because Peter did it with sbhttpd. It turned out better than I anticipated and the icing is it works with MT.
Title: Re: SBOCX
Post by: John on January 18, 2019, 07:49:39 PM
Mike,

I took a peek at my OCX forms example code as a base to build the SB.ocx control. It looks like Dave has the SB function callback as a function in his COM extension module DLL. I have't investigated if a scriba load feature exists or not in the DLL. This may a bit more work than I anticipated but I still think it's worth the effort. I would like to get your take on doing this.

How to develop and deploy ActiveX control in C# (https://blogs.msdn.microsoft.com/asiatech/2011/12/05/how-to-develop-and-deploy-activex-control-in-c)

The SB.ocx must do the following.



Title: Re: SBOCX
Post by: Mike Lobanovsky on January 19, 2019, 05:04:16 AM
John,

First and foremost, please note that developing ActiveX controls in C# and deploying them is probably the last thing I'm prepared to be engaged in ATM.

Now consider the following before you put your efforts in your MT OCX venture:Proceed with your work only iff you can justify it in view of all the points I noted above, or your interest is of purely scientific nature, or it's just a challenge to test your skills.
Title: Re: SBOCX
Post by: John on January 19, 2019, 09:17:14 AM
Quote
Proceed with your work only iff you can justify it in view of all the points I noted above, or your interest is of purely scientific nature, or it's just a challenge to test your skills.

All I'm trying to do is what you and I  just worked on with PVXCOM, only with SB not ProvideX. The C# example was just that. (how to write a OCX outside of VB) I'm all ears what you recommend using to build this OCX front end to SB.

I going to give what already works with Dave's COM extension module. The OCX isn't running multi-threaded, SB is. The OCX is just an interface.

Quote from: Karl E. Peterson
Microsoft had never rendered any of their customer's data unusable. Not once. Why they did it first to the users of the world's most popular programming language ever, the product the company was founded upon and that may have had more impact on their overall corporate position than any other, is extremely puzzling. After years neglecting the VB6 community, Microsoft seems to be missing something. Us!
Title: Re: SBOCX
Post by: John on January 19, 2019, 10:33:12 AM
I may use the threaded option for MODULE objects like IUP that has a message loop that needs to run. Using the RUN option is more flexable and for most method calls will work fine.

I looked at the COM extension module and there isn't a means to start a SB main instance. It assumes SB is the host and loading the COM as an extension.

Unless Mike has an idea how an OCX interface for SB can be created without a lot of work, I'm going to have to be happy with where things are at on the Windows 32 bit OCX front.
Title: Re: SBOCX
Post by: John on January 19, 2019, 04:38:28 PM
I might just create an OOP extension module using the same cocepts I had with the OCX direction.
Title: Re: SBOCX
Post by: John 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>


Title: Re: SBOCX
Post by: Mike Lobanovsky 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.
Title: Re: SBOCX
Post by: John 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.
Title: Re: SBOCX
Post by: Mike Lobanovsky 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. :)
Title: Re: SBOCX
Post by: John 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.
Title: Re: SBOCX
Post by: John 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.
Title: Re: SBOCX
Post by: Mike Lobanovsky 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.
Title: Re: SBOCX
Post by: John 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.  

 
Title: Re: SBOCX
Post by: Mike Lobanovsky 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.
Title: Re: SBOCX
Post by: John 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.
Title: Re: SBOCX
Post by: John 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.
Title: Re: SBOCX
Post by: John 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 (https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6.0-documentation)

Title: Re: SBOCX
Post by: John 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 ==========




Title: Re: SBOCX
Post by: John 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.



Title: Re: SBOCX
Post by: John 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.
Title: Re: SBOCX
Post by: Mike Lobanovsky on January 30, 2019, 05:54:30 AM
Sorry but the meaning of that message eludes me completely. Can you elaborate on what you were trying to convey?
Title: Re: SBOCX
Post by: John on January 30, 2019, 09:03:42 AM
I seem to be chasing my own tail with VB6.