Groups > Superbase > Superbase NG > Re: Calling SIMPOL from SBL




Calling SIMPOL from SBL

Calling SIMPOL from SBL
Mon, 29 Oct 2007 11:31:41 -060
Are we ready for prime time with calling a SIMPOL function from SBL in RTS? And
what files, exactly, would we ship?

Post Reply
Re: Calling SIMPOL from SBL
Mon, 29 Oct 2007 13:45:32 -040
Peter Barus wrote:
> Are we ready for prime time with calling a SIMPOL function from SBL in RTS?
And what files, exactly, would we ship?
> 
> Peter

What possible function could you write in SIMPOL that you can't do 
already in SBL.

I don't get the point.

Post Reply
Re: Calling SIMPOL from SBL
Tue, 30 Oct 2007 08:49:41 +000
Kromkowski wrote:
> Peter Barus wrote:
>> Are we ready for prime time with calling a SIMPOL function from SBL in
>> RTS? And what files, exactly, would we ship?
>>
>> Peter
> 
> What possible function could you write in SIMPOL that you can't do
> already in SBL.
> 
> I don't get the point.

Knowing Peter's application, he could probably make use of a number of
common dialogs that are not available in SBL, like the color picker, the
font picker, the Win32 versions of the file open, file save, and
directory picker (with new directory button option). These are just to
name a few. I have built things like TCP/IP communications for some
customers into their applications using SIMPOL, where they wanted to
have a custom access method to reach a corporate database that only had
a TCP/IP access layer. SIMPOL also provides full access to the XML DOM
(Document Object Model) with full Core Level 1, Core Level 2, and
partial Core Level 3 support. This can also be very handy. SIMPOL
provides DLL access, as does Superbase, but can natively and more
thoroughly access Win32 functionality.

A lot really depends on what you need and how you use the product. I
wrote a SIMPOL library that can directly read and parse SBF files. I
could never have written this in SBL, since you can't open binary files
for input in SBL.

I am sure others can give you more examples. That is completely
independent of the fact that someone like Peter can begin converting
certain modules in his code and still call them from the old, so as to
get a jump on the conversion process.

Post Reply
Re: Calling SIMPOL from SBL
Tue, 30 Oct 2007 09:18:14 +000
Peter Barus wrote:
> Are we ready for prime time with calling a SIMPOL function from SBL in RTS?
And what files, exactly, would we ship?
> 
> Peter

Peter,

although you can call SIMPOL functions from SBL as DLL calls, and you
can also call SIMPOL programs with command line parameters using the
CALL "" syntax, I assume that you know that. If you really mean, can
you
ship bits of SIMPOL with your application, until we finally release the
thing, the system is still time-bombed. If you are shipping to a small
group of people and can make sure they update every time you send them
an update, then the time-bomb shouldn't be a problem for you. The system
is designed to last for 180 days from compile date, so the window is
fairly wide to get an update to people.

As for what you ship, that depends greatly on what you use in your code.
SIMPOL is very much a component-based architecture.

You always need some way to run the program, so you either need:

smprun32.exe   Console programs
LINUX: smprun

smpwin32.exe   GUI programs
smexec32.dll   Calling functions as DLL calls

For web server applications you need either:

smpcgi32.exe   CGI
LINUX: smpcgi
smisap32.dll   ISAPI (Windows only)
smfcgi32.exe   FastCGI
LINUX: smfcgi

You then need SMPOL32.DLL (LINUX: libsmpol.so), which contains the language.

If you are using a component, then you need its DLL too:

smlxml32.dll  LXML component for XML DOM, also needs:
  libxml2.dll
  libxslt.dll
LINUX: libsmpollxml.so, the libxml2 components should already be on the OS.

smppcs32.dll  PPCS Client access component, also needs:
  sbsort32.dll
LINUX: libsmpolppcs.so, libsbsort01.so

smsbme32.dll  SBME Single user database engine, also needs:
  sbsort32.dll
LINUX: libsmpolsbme.so, libsbsort01.so

smppsr32.dll  PPSR Multi-user database engine, cannot be distributed
currently, but will soon be purchaseable for distribution. The engine
requires an unlock code and a registration number and is specific to an
installation. The installation by the SIMPOL Developer Kit installer
sets it to 3 concurrent connections for testing from your machine. It
also needs:
  sbsort32.dll
LINUX: libsmpolppsr.so - currently limited to 1 user until the installer
is available (except by special arrangement), plus libsbsort01.so.

smslib32.dll  SLIB Shared library access (currently only available for
Win32)

smsock32.dll  SOCK TCP/IP socket component for client and server
LINUX: libsmpolsock.so

smutos32.dll  UTOS O/S Utilities, currently UTOSdirectory and
UTOSdirectoryentry objects
LINUX: libsmpolutos.so

smwxwn32.dll  WXWN wxWidgets GUI components for SIMPOL, currently
Windows only. Also requires the wxWidgets DLLs:
  wxbase28u_vc_simpol.dll
  wxmsw28u_core_vc_simpol.dll
  wxmsw28u_adv_vc_simpol.dll


Post Reply
Re: Calling SIMPOL from SBL
Tue, 30 Oct 2007 11:07:31 -040
>> Peter Barus wrote:
>>> Are we ready for prime time with calling a SIMPOL function from SBL
in
>>> RTS? And what files, exactly, would we ship?

>>Kromkowski wrote:
 >> Peter
>> What possible function could you write in SIMPOL that you can't do
>> already in SBL.
>>
>> I don't get the point.
> 
Neil Robinson wrote:
> Knowing Peter's application, he could probably make use of a number of
> common dialogs that are not available in SBL, like the color picker, the
> font picker, the Win32 versions of the file open, file save, and
> directory picker (with new directory button option). 

JDK:

Are you saying that the WIN32 versions of file open, save and directory 
picker ARE not accessible via SBL calls to the WINDOWS API? Whatever 
limitations that SB has, they are pretty minor -- otherwise it would be 
hard to do very much.

Or that the colorpicker dialog can't be called via the windows api?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/win
dowsuserinterface/userinput/commondialogboxlibrary/colordialogbox.asp

It just seems like those examples are pretty convoluted reasons to make 
SIMPOL calls from stable SB program.

>NR: These are just to
> name a few. I have built things like TCP/IP communications for some
> customers into their applications using SIMPOL, where they wanted to
> have a custom access method to reach a corporate database that only had
> a TCP/IP access layer. SIMPOL also provides full access to the XML DOM
> (Document Object Model) with full Core Level 1, Core Level 2, and
> partial Core Level 3 support. This can also be very handy. SIMPOL
> provides DLL access, as does Superbase, but can natively and more
> thoroughly access Win32 functionality.

I really don't understand what this means "that SIMPOL can natively and 
more thoroughly access Win32 functionality".

> A lot really depends on what you need and how you use the product. I
> wrote a SIMPOL library that can directly read and parse SBF files. I
> could never have written this in SBL, since you can't open binary files
> for input in SBL

I suppose I thought that is what EXPORT is for!

But ironically, this works:
REQUEST IF ("C:\SB4W\yourfile.sbf" CONTAINS
"*yourword*","Yes it 
does","No it doesn't")

On the other hand, if SIMPOL can directly read and parse SBF files, 
which I have no doubt it can, I guess I don't understand why there isn't 
a direct conversion from SBF to SBM utility that is part of 
dataconvertwx.smp.

> I am sure others can give you more examples. That is completely
> independent of the fact that someone like Peter can begin converting
> certain modules in his code and still call them from the old, so as to
> get a jump on the conversion process.

I don't get this idea of "getting a jump" on the conversion process. 
Either there is a product into which you can convert your whole 
application or there isn't.  In which case you do it.

I can't wrap my head around why you'd want to do it piecemeal.

The reason for SIMPOL is ostensibly because SB2 and SB3 won't run on 
Vista 64-bit machines.

What must be part of the vision is that you want everybody whose running
SB2 and SB3 applications to be able to convert to SIMPOL.  I don't mean 
in the sense of backward compatability.

I hope that Peter answers the question I asked him.

Post Reply
<< Previous 1 2 3 4 Next >>
( Page 1 of 4 )
about | contact