Navigation Menu

[Michael]

JDK wrote:
> I'm pretty sure it is correct. I can google for code as well as the
> next fellow.
>

Try it then from Superbase, does it work? Or from Excel. The first step
is making sure it works at all. I have had no end of support calls when
I was at Superbase complaining that Superbase wasn't working, only to
discover the actual problem was not a part of Superbase at all, it would
turn out to be something totally unrelated, but because they were trying
it from Superbase, Superbase was broken.

Ciao, Neil

[Michael]

gerald******@**ser.com wrote:
>
> I have quite a lot of SBP's (2001) from my point of view simple
> programms.
>
> what is the best way to try converting them to simpol.

Hi Gerald,

A lot depends on what the programs do, and how they work. For example a
simple program that just does a bunch of updates with calculations and
such can easily be converted. Or something that uses a bunch of dialogs.

It really depends on what you are starting with.

Ciao, Neil

[Michael]

JDK wrote:
> Neil Robinson wrote:
>
>> If you are opening a form and allowing it to open the tables, and
>> if you are using the sbme1 method of opening them, then it will
>> fail. The way around this is to open the tables first, and then
>> pass in a valid dring of datasourceinfo objects, plus a valid array
>> of tbinfo objects. This allows the form to use the existing tables
>> and datasources rather than needing to open them again. This will
>> be part of a more comprehensive example that I am currently working
>> on.
>
> Well, I opening a form by using f =@ opendataform1(filename, error=e,
> errortext=errtext)
>
> What you are suggesting sounds so complicated.
>
> I should be able to open any form using opendataform1 and put it into
> any window that has been created, without all that rigamorale.

What you suggest will work fine, if you are using only PPCS data
sources. If you are using SBME data sources, it won't work, since you
cannot open the same file exclusively twice. SIMPOL Personal's API will
provide these facilities for people who wish to deploy using the
services that SIMPOL Personal will make available.

> Eg, if this can't work in a straightforward way then this really
> doesn't seem to be RAD. Here is about the simplest example I can
> think of to test whether this is working correctly. I've left out so
> tidying tests to see if form and or window was appropriately created.

This has nothing to do with RAD, this has to do with an inability to
open a database container exclusively in more than one place in the
code. I grant you, that makes it more complicated to work with
single-user databases, but we will provide the SIMPOL Personal API route
to make that easier for those who wish to travel that direction.

> // open four forms // IT SHOULD NOT MATTER what forms you choose

This is a bit unrealistic. The form design assumes that it can open the
data sources, but it can cater for not being able to do so. If you try
to open the same database exclusively in two different view windows in
Superbase it would also fail with the message that the file is already
open for exclusive access.

> As far as the "example you are working on", You should just make the
> personal code available. I'm really not sure what you are trying to
> protect. It seems like the short term over the long term.

No, the company has a specific medium and long term product strategy.
The examples I am working on are related to that strategy, as is the
existence of SIMPOL Personal. There is a reason why the opendataform1()
function takes as many potential parameters as it does, including a
dring of datasourceinfo objects and an array of tbinfo objects. It
allows the application to manage the data sources and the form to make
use of already opened data sources and tables rather than trying to
reopen them itself.

Ciao, Neil

[Michael]

JDK wrote:
> OK. I take it that there is no documentation for this, yet.
>
> I tried to do OLE with WordPerfect.
>
> I get warning
>
> cannot get CLSID from ProgID

The warning is pretty clear. You have supplied an object name that is
not able to be turned into a class ID. You would need to first do some
checking on using OLE2 with Word Perfect, to make sure the methodology
is even close to right.

> and error 529.

I haven't documented that one (it is new) but I would guess it is a
general purpose OLE2 error.

> I don't know enough (since heretofore it was always easier to use
> DDE) to know whether the trouble is me, or WP or Simpol.

At some stage we may have DDE client capability, but is simply not yet
high enough on the priority list.

Ciao, Neil

[Michael]

kromkowski wrote:
> There seems to be a bug in the OLE example. The error is 21. So I
> think that the problem is that chartobjects isn't getting created (it
> remains .nul)
>
>
> chartobjects =@ worksheet.getobject(property="ChartObjects", error=e)
> * chartobjects.callmethod(method="Add", 50, 90, 270, 150,
> error=e) e = 0
>
>
> I don't use Excel so I don't know enough to sort out whether the
> problem is in Simpol or in how you tried to implement it.
>
> When I ran a record macro in Excel to do basically what you were
> trying to do I got this:
>
> Range("C1:C5").Select ActiveSheet.Shapes.AddChart.Select
> ActiveChart.SetSourceData Source:=Range("'Sheet1'!$C$1:$C$5")
> ActiveChart.ChartType = xlColumnClustered Range("B9").Select
>
>
> Although, this http://support.microsoft.com/kb/142387 suggests
> something closer to what you were doing.
>
> oChart = oSheet.ChartObjects.Add(50, 40, 300, 200).Chart
>
> On the other hand your example is straight from the Superbase,
>
> REM This creates a chart embedded in the current sheet REM using the
> Excel default format s.Range("C1:C5").Select() s.Selection.Copy()
> s.ActiveSheet.ChartObjects.Add(50,90,270,150).Select()
>
> which does work.

Thanks for that. I just had a look, and it may for some strange reason
depend on the version of Excel, since this example works ok here using
Excel 2000. It may be any number of things. I don't think this is the
last word on the OLE2 stuff, but we will need a lot more data before we
can go further. We are just passing these calls off to wxWidgets
currently. The example will need to be corrected though to check for
success there then.

Ciao, Neil

[Michael]

Kromkowski wrote:
> Is there a trick involving locking or unlocking?

If you are opening a form and allowing it to open the tables, and if you
are using the sbme1 method of opening them, then it will fail. The way
around this is to open the tables first, and then pass in a valid dring
of datasourceinfo objects, plus a valid array of tbinfo objects. This
allows the form to use the existing tables and datasources rather than
needing to open them again. This will be part of a more comprehensive
example that I am currently working on.

Ciao, Neil

[Michael]

Bert Lundberg wrote:
> I work with Superbase Ver 2.01. I export sbf-file to csv-file with my
> own routine. I import the csv-file in Simpol Personal. When I try to
> create index Simpol give me "Error number 63 updating the table in
> the *.sbm file" with SB Compatible and number 914 with Unicode Index
> Algorithm. This i the 2nd table in container file. In the first table
> was no problem to create index.
>

Hi Bert,

An error 63 usually implies an index problem in the table. Error 914 is
a duplicate index entry on an index set up as unique. I strongly urge
you to use the SB Compatible index as a rule, since it does a very good
job of not only being Superbase compatible, but i understands upper and
lower case across most of the first 900 Unicode characters, whereas
Unicode order just understands that, which means it will not sort upper
and lowercase together.

I also suggest that you stick with one table per container file for now,
since it will aid in doing system updates and provides a performance
boost when doing reorganization.

Ciao, Neil

[Michael]

Eddie Hann wrote:
> I have a flat file database of over 80,000 records. There are two
> fields with one unique index. – "QUESTION" and "ANSWERS" The answers
> field has been assigned a 4,000 character length. Between each
> answer, (word of phrase), there is a carriage return to make them
> columnar for easier reading, like the example below.
>
> Discordance [Lack of agreement] Uncooperativeness Etc Etc Etc
>
> The information I'm seeking is this – Will simpol Personal be able to
> directly access this superbase file, or will it require importing?
>
> If importing, how will it handle this columnar arrangement with its
> multiple carriage returns?
>
> Thanks in anticipation,

Hi Eddie,

SIMPOL Personal cannot currently import Superbase (*.SBF) files, though
we do have a standalone tool that can do the import. That tool just
needs to be rechecked to ensure that it recognizes password-protected
files (which it will may not be able to open – encrypted ones would fail
anyway). That tool will be able to directly create the new database
engine format from the old one, including handling the formatted long
text fields that you describe. The import tool should be available
either as part of the next quarterly release, or failing that, shortly
thereafter as a download from the library.

Ciao, Neil

[Michael]

Lawrence Ward wrote:
> The previous description was accurate. The data type used was date
> M/D/Y with a leading zero for month. Initially three different date
> fields were included. The first date field, identical to the others
> is where the system crashed. The others did not. Also, if I
> entered data in other text fields, there was no crash. My solution
> was to delete the initial date field. As a result the others worked.
> (I determined that I could do without the field.

Thanks, I will try and reproduce that.

> However SIMPOL Personal is still crashing, Neil, even with the more
> recent file. It crashed in the form designer area when I used the
> Select All feature in on the menu. Total shut down.

I will have a look at that as well. The thing to probably explain here
is that if SIMPOL encounters a syntax error at runtime, the program
exits. There is currently no exception handling that can keep it going.
Most things in SIMPOL that can cause a normal runtime error, like
failing to open a file, take an error parameter, and should then fail
gracefully, though there may still be a few places where it fails
anyway, and I would like to remove as many of those as possible.

> It also shuts down after an import regardless of file type (XML, CVS,
> ASCII). The good news is that when started back up, the file import
> was successful. It shuts down when you hit the directional arrows.

OK, I will try that, thanks.

Ciao, Neil

[Michael]

Lawrence Ward wrote:
> I tried entering data into a newly created table with a date field
> and SIMPOL Personal shut down. It's had the same response twice in a
> row. It was the first record of my table.
>

Hi Lawrence,

Can you give me more information here? When you entered the date, what
format did you enter it in? Also, what format is recorded in the table
definition for the date field? I have had reports of this before, but
have never been able to reproduce the problem, so any inforamtion you
can give me would help, thanks.

Ciao, Neil

[Michael]

Lawrence Ward wrote:
> I tried importing an XML file and SIMPOL Personal shut down.
>

Can you give me more information about what you were doing? Were you
merging or creating a new file? What format was the xml file in (can you
send me a sample record or so from the top)?

Ciao, Neil

[Michael]

JDK wrote:
> Neil Robinson wrote:
>> JDK wrote:
>>> Importing causes Shutdown.
>>>
>>
>> I had a similar problem with the ASCII-Delimited converter, which I
>> have fixed in the final release. Which converter were you using?
>>
>> Ciao, Neil
>
> The import function in personal in lastest release.

Yes, I gathered that. Which format were you importing?

> I'm still not clear why it is that you don't have an import for
>
> Dbase .dbf
dBase format would require us to license a third-party library, unless
we were willing to do it ourselves. In either case, it is not currently
worth it. When you are deciding what to support you have to vote with
what the customers most need.

> Excel .xls
Which format? There are more than 10. The documentation that is
available from OpenOffice.org about the reverse-engineered MS Excel
formats runs to over 200 pages. Supporting native Excel import is
non-trivial.

> superbase (Your concern about password protection to me is misplaced
> given the demise of SB PLC vs. the vision of having old SB users
> migrate to SIMPOL)

I may include an importer for Superbase format directly into SIMPOL
Personal for the next release. It will still respect passwords (but may
not be able to open tables that are password protected). If not, I will
include a Superbase utility to remove all the passwords from a directory
of tables (assuming you know the passwords). It won't be able to open
encrypted Superbase tables.

> Paradox .db

Same reason as dBase. When somebody needs it, we will do it.

> Data Interchange Format .dif

Same reason as dBase. When somebody needs it, we will do it.

> .adr and related address book formats

Address book formats are more of an application-level import capability,
but if these become necessary for something, we will code them then.

> Sql databases .frm, .myd, etc.
> Access mdb, etc

Any SQL-based import will probably have to go through ODBC. We are not
ready to ship the ODBC client support that we have, it isn't yet ready
for that level (some additional functionality that is not directly SQL,
but more ODBC Admin is required).

Ciao, Neil

[Michael]

JDK wrote:
> Importing causes Shutdown.
>

I had a similar problem with the ASCII-Delimited converter, which I have
fixed in the final release. Which converter were you using?

Ciao, Neil

[Michael]

jdk wrote:
> Neil Robinson wrote:
>> John Kromkowski wrote:
>>
>>> I was explicitly advised that detail blocks were part of this
>>> release. But alas, they are not.
>>
>> I am a little surprised, since I am sure we specifically said that
>> they would not be ready for this release, but that data-aware grids
>> would be.
>
> Well, perhaps I am mistaken I thought I asked Rufus the question
> during the conference. I'm not sure that going through the record
> will be of any help at this point. You might also look at your
> 10/14/08 post, which made it sound like the code was done.
>
> But you'd have to admit that even a data-aware grid that doesn't
> support sorting is basically not much of a sophistication over the
> grid stuffing thing I previously posting.

Unfortunately, the grid control we are using doesn't provide for buttons
being inserted into the control. The only way to do sorting is via a
popup menu. We *are* looking at another control that is more like a
listbox, but with columns and clickable headers, but until that is
wrapped, we will have to live with the standard grid. As for the thing
you recently posted, which is little more than a basic table view, this
one is generic, linkable to other tables that themselves are controlled
by their own links, can support additional linked columns within the
block, etc. A large part of the development time was spent also creating
the linking tools. The programmatic version I had working fairly
quickly, the drawing support for the Form Designer was a lot more work.

> Surely, if you revealed bit of the code you`re using to do the
> data-aware grid, somebody here could whip up pretty quickly a
> programatic version detailblocks, to tweek the dataform program
> generated by the save as in the form designer.

A programmatic version of detail blocks that does what? It would have
been fairly trivial to give you single-level detail blocks. The problems
begin with the more advanced features, and unless they are accommodated
in the original design, the risk is very high that anything I released
early would be broken by later changes.

> I may even try my hand at but it would be kind of pathetic if the
> lawyer non-programmer worked it before everyone else.

Be my guest. If it were that simple I would have released them by now.
Don't forget that Superbase detail blocks support both rows and columns,
can be nested up to 8 levels deep, can have linked tables, each block
can be sorted ascending or descending, can have scroll bars (right or
left), and will need to support potentially thousands or even millions
of dependent records efficiently. They can also be unlinked. What do you
intend to do with the records that have been changed? If the form is
locked, do you lock all the records? When do you save changes? If you
don't commit them early, what happens when a changed record scrolls off
the screen? How do you add new ones? How do you delete a row? How do you
make sure it runs fast?

I have looked at all of these issues while doing the design work, plus
more as well. If you think you have a brilliant solution, I am all ears.
There is probably a good reason why you have never seen detail blocks in
any other commercial product. The design is difficult beyond belief to
get right and have work efficiently. Even the one in Superbase has
numerous flaws that we are all aware of, such as dealing with new
records after the first page is full, or deleting records.

Ciao, Neil

[Michael]

John Kromkowski wrote:

> I was explicitly advised that detail blocks were part of this release. But
> alas, they are not.

I am a little surprised, since I am sure we specifically said that they
would not be ready for this release, but that data-aware grids would be.

> I see the data-aware grid. It isn't quite the same thing.

Sure, it doesn't support multiple levels and doesn't support disparate
controls.

> First, I can't sort the child data.

I appreciate that. This is a first cut, meant primarily to invite comment
since this is the point where we can make changes and improvements before
it is set in stone.

> Second, I can't get rid of the row labels.

You can't do it graphically, and you probably shouldn#t be able to do it
(but you can) programmatically. The issue here is that once they are made
read/write, the row labes area will be used to indicate which row is being
changed, whether the row has been changed, etc.

> Third, I can't control the graphic properties. In Form Designer, you can
> select the data-aware grid, and right mouse and chose graphic properties
> and "seem" as if you are changing things. But nothing obviously "sticks".

Sorry about that. I will have to make sure that you can't select graphic
properties if you have the grid selected. If you double click on it, you
will see what can be done to the grid. If it isn't there, you shouldn't
look for it elsewhere. Some things can be changed programmatically. (You
can set the rowlabelwidth to 1 for example).

> There are other niggles, which I've leave for later.

I am sure there will be more, but we needed to start this process moving.

Ciao, Neil

[Author]

Posts