Navigation Menu

[Michael]

Jim wrote:
> Huh?
>
> I am trying to convert some forms from superbase to Simpol forms. I
> use the tool provided to generate an xml file, then try to load it
> into superbase personal, and this is the error message I get.
>

There is an update to this tool, look in the demos library. There was a
mismatch between the form converter and the DTD.

Ciao, Neil

[Michael]

Jim wrote:
> I'm trying to use a bitmap image as a form backdrop.
>
> Problem is I can't seem to set the z-order and it is appearing in
> front of all my controls except for a label.
>
> I use the setnext method, but it doesn't seem to do a thing. The
> description of setnext is that it sets the z-order AND the tab order.
> But I can't tell if "highest Z-order" is front or back, and the
> method doesn't seem to affect how the form is displayed anyway.
>
> How do I set a bitmap image to be at the back, with everything
> displayed in front of it?
>

Create the bitmap first. But, please note that the graphic controls are
all lower in the z-order than any form control, including bitmaps. So
lines, rectangles, triangles, ellipses, and arcs will all appear below
the bitmap. Otherwise, z-order is control creation order, with the first
appearing at the bottom, and the others appearing above it.

Ciao, Neil

[Michael]

Jim wrote:
> of course, the fact that I will be using multiple threads is the
> reason I was asking about pass by value vs pass by reference.
>
> Is the taking of a lock guaranteed to be atomic, such that I can't
> get into a problem if two threads simultaneously try to take a lock
> (which potentially is possible on a multiprocessor system)? Low
> probability event, sure. But if it can happen, it will, and
> corrupting data is to be avoided at all costs.
>
SIMPOL's threading is implemented internally, not using system threads.
As such SIMPOL would handle the thread concurrency anyway, but the call
to the lock1 object's lock() function is atomic. Only one will succeed.

Ciao, Neil

[Michael]

Chris wrote:
> I would like to see detail blocks working much as they do in
> Superbase. Additional features, such as a right-click for deleting a
> row, may be useful as long as you can revert to the original
> implementation. The initial adopters of Simpol will be ex-Superbase
> users who will be familiar with detail blocks as they are and most,
> such as myself, will want to port applications to Simpol with as
> little re-design as possible.
>
> I see no attraction in a read-only detail block with buttons, as has
> been suggested elsewhere in this forum, as it undermines the power of
> detail blocks for rapid data input, such as when entering many items
> on an order form.

That is a good point. For detail blocks that are being used in this way,
all the standard Superbase design decisions work fairly well, up to and
including creating a new row when the user tabs out of the last visible
row. I am inclined to say that even that behavior should be an option
that is enabled or disabled.

Ciao, Neil

[Michael]

JDK wrote:

> OK, but being able to sort the detailblock the way you want I think
> is essential.

I agree. It is just important that people realize that it can be a
performance issue with large numbers of records (or if they are
retrieving their data over a slow connection).

>
>> Some people do it this way in Superbase, others do it by defining a
>> row at the top that is not actually part of the block, but which
>> acts as if it were, and every selection is copied to that row.
>
> Wow, talk about a kludge.

I have seen these apps. They work, the solution is intuitive and fairly
elegant, and it keeps the user on the form instead of opening a dialog
for data-entry.

> OnCellSelect event
>
>> Actually, I use the oncellselect event of the grid to get that
>> information.
>
> I've not been able to successfully get that to work with the
> data-aware grid.

Hmm. It should work. I will have a look see.

Ciao, Neil

[Michael]

John Roberts wrote:
>> Mark a row (visually as selected) Select one or more rows (do I add
>> a checkbox potentially to the beginning of each row?)
>
> One of the good things about wxWidgets was it used native controls as
> opposed to Java etc. I appreciate a detailblock is not a native
> control but it should look like one otherwise it might end up like SB
> later in its life.

Possibly, but there is nothing like detail blocks that I am aware of.
everything else is just a grid with a single level in it. Some grids
allow the inclusion of additional controls (the wxGrid does not, by the
way, it has a couple of things it supports, like the combobox like cell,
but you can't just embed what you want in a cell, we investigated that
early on). Anything that gets decided on this level will be optional, of
course. The programmer can turn any of the things I am discussing on or
off. They are meant to provide easy-to-use default functionality, not
ram it down everyone's throat.

> An overlaid semi-transparent rectangle with each control coming
> forward in Zorder onGotFocus? It could be resizable to accomodate
> different size row controls and multi consectutive selections.
> Perhaps another to accomodate the "Glow" onmouseover mentioned in
> another post. It is becoming standard these days but depends how far
> you want to go. I think the programmer should be able to place their
> own checkboxes. That sounds like something you could implement in the
> personal edition but not for professional.

Basically only underlaid graphics are possible due to the way the
z-ordering works. I intended to size it according to the row dimensions,
whatever they might be. Since onmouseover is not an available event
(onmouse is, and I might be able to swing something here, but no
promises yet). As for the programmer placing their own checkboxes, they
will certainly have the ability to do that. They wouldn't be part of the
detail block, but outside it, of course.

>> Add a record, Delete a record etc.
>
> Up to the programmer isn't it unless you are thinking of the personal
> edition? Commands to insert/display added data or redisplay if
> cancelled are necessary. Got to be able to blank a row – any row and
> also edit any row "in-situ". If someone wants to add a row extra "off
> DBlock row" for editing/new then its up to them to decide where and
> what controls they add. It wouldn't be much good if other undisplayed
> fields couldn't be included and another set of controls had to built
> to do this.

As I said above, all of the things that I am planning to add to the
detail blocks in this general vein will be optional and can be switched
off by the programmer. As for blanking a row, any row, that depends an
awful lot on how data is added to the detail block. If someone blanks a
given row (by creating a new record), the issue arises what should be
done with the rest of the data. If the row is not committed, where does
it go in the sort order? Do I move it to the correct sorting position
(assuming there is one)? Do I leave it where it is and move everything
down? If instead they add the row via a dialog, the issue arise of is it
committed? If so do they insert it, or do I refresh the detail block and
reset to the top (like Superbase does)?

>> Thinking about it though, there is a real problem with adding
>> records, since if they scroll off, how do you reselect them? They
>> won't yet exist in the database, so there is no way to add them
>> back into the sort order.
>
> I don't think there is any solution to this other than some virtual
> store of records whether it be all the records retrieved so far or
> just the uncommitted new/edits. You have a record object so why not
> collect them with a new/edit flag (unless it is void without a table
> object and disk file). Populate from this. SelectNextPage() goes into
> the store and is used to populate the DBlock page. Store saves only
> the flagged.

I had already decided that a virtual store for edited and new records
would need to exist. Any time the user scrolls the detail block, then
the code would have to check the virtual store as it reselects records.

> If the v store kept only new/edited records then it could be checked
> for the presence of a record that might fit in the current page sort
> order and the appropriate record inserted. Screen updates for
> displayed records changed elsewhere are a problem. Does the DBlock
> request an update periodically or does the server notify its clients?
> I suppose there are no persistent clients with peer to peer so it
> would have to be the former.

As the detail block is scrolled up and down, records outside the visible
range will be reread. If there are new ones, they will appear (which
affects the sorting of newly created but not yet committed records).

>>> Editing a detailblock with intra row links is not easy unless you
>>> add a button in a "border" cell between one table and the next in
>>> the same row.
>
> To clarify, I meant this needs to be done by the programmer.

That may be true, but the detail block design needs to foresee and
accommodate these sorts of issues.

>> Actually, I would always make these controls read-only/disabled.
>> The only way they could get their content filled is by exercising
>> the link.
>
> I ended up doing this (readonly) in SB. It was too fiddly otherwise.

The problem is that in 99.9% of cases, you shouldn't be locking and/or
changing a record in a lookup table this way. The rare case is where
someone has designed an extension table to the original which is
one-to-one with the other table. In these rare cases, the programmer can
manage this by themselves. Most people would just extend the table
definition to add the required fields.

>>> If you add a right click menu, it needs to be able to be
>>> overidden and/or appended to.
>>
>> That was the intention. A menu with Add, Modify, Delete, which can
>> be added to after Delete. The main entries can be disabled if
>> required. Modify and Delete will also be disabled if no row is
>> currently selected. Selecting one would just call the associated
>> callback function.
>
> I suppose some sort of menu might make it quicker to place a DBlock
> on screen but I don't think this is your responsibility (perhaps it
> is in personal edition) but you do need to provide the means to
> easily place a menu and appropriate onclick events and retrieval of
> which physical row/control is clicked and which record is in there if
> it is linked to a dbase. I agree with a later post about not placing
> new/edit buttons as an integral part of the DBlock.

Actually, there is no difference between Personal and the rest. It also
just uses the facilities provided. As for the other bits, if you click
on a control, every one of them has an ongotfocus event and the the
handler function, if defined, receives the control as an argument. Once
you have the control you can find out which row it is in, which detail
block, etc. There is a method for retrieving the record associated with
a given row. Adding buttons was just a discussion topic. Again, were
they to bae added as an integral option, the functionality could be
disabled.

>> Doubleclick events don't really exist for everything I think (maybe
>> onmouse can help here though).
>
> They need to exist or at the least a method to distinguish between
> single and double click.

Not every control has a click event. All controls have an ongotfocus
event. Checkboxes and option buttons have an onchange event, pushbuttons
have an onclick event, edit controls have a number of events, but no
onclick. All controls have an onmouse, which provides quite a wide array
of events that you can ask it to watch for:

left button down
left button up
left button double click
middle button down
middle button up
middle button dbl click
right button down
right button up
right button dbl click
motion

>> Again, are we talking about selecting a control, or selecting some
>> piece of window dressing that is trying to indicate a row is
>> selected?
>
> Probably both but not just trying.

The real issue with deciding what indicates a row is selected is
deciding what it will look like, how it is implemented, and to what
degree it can be modified by the programmer.

>> Detail blocks are not grids. They are more versatile than grids.
>> For grids, I already have dataform1datagrid. Ciao, Neil
>
> With the grids built in selection capabilities etc it is a pity the
> controls can't be rendered straight onto the grid for different data
> types/display controls. Then I think DBlocks would be more versatile
> only in the way they have dbase links/display capabilities. Scroll
> the data, not the physical rows. Cheers, John

True, but this limitation is built into wxWidgets. Although we could
potentially change that, it is not a trivial task.

Cioa, Neil

[Michael]

JDK wrote:
> So I seem to have lost the debug tools. The debug toolbar is there.
> But it's just blank. I can move the empty thing around. I can turn
> it on and off. But it has nothing in it?
>

That is very strange. So you can see the toolbar itself, but there is
nothing in it? My immediate thought is to do a restart and see if it
persists. If it does, it may be necessary to delete a set of keys from
the registry.

Ciao, Neil

[Michael]

JDK wrote:
> NR: "As for the row numbers, I am pretty sure you can change them
> programmatically yourself, just call the setrowlabelwidth() method I
> think it is."
>
> Ok, I see this method, now. And if you set the width to (1), you can
> essentially make the label disappear. (setting to 0 causes error)
>
> But shouldn't I really be able to set this while using the Form
> Designer?
>
> And if I just create the form (saved as .sfx) and then use
> opendataform1(), I really can't easily be doing this.

True, but the row area was being reserved for telling the user which
record they are on, and also for later indicating that a row has
changed, or is being modified, etc. so I did not intend for people to be
able to directly modify except programmatically. I can certainly make
the default width smaller.

Ciao, Neil

[Michael]

Jim wrote:
> Suppose, upon starting a simpol program, I define an object and
> initialize it in some appropriate fashion.
>
> Then, I spawn a new thread, and pass a reference to this object so
> that the new thread can use what is in it.
>
> Then, I terminate the thread that created the object.
>
> Will the object continue to exist because there is a valid reference
> to it? Or does the reference become invalid?

As long as a reference to an object exists, it will continue to exist.
Once the last reference is gone, the object is destroyed and the memory
freed. There is no garbage collection.

> Also, how can I pass an object by value rather than by reference, for
> those circumstances where this would be appropriate?

If you want to pass a scalar type (integer, number, boolean, blob, or
string), the easiest way is to do this:

string s

s = "hello"
foo(string.new(s))

There is no method for passing a copy of a complex object. Also, in a
multi-threaded environment, it is important to be aware of the fact that
concurrent threads may be modifying the same common object. If this is
likely to happen, you can control access to the object (or sections of
it) by inserting lock1 objects into the object as well. Before accessing
the object or a specific part, you can get a lock on the lock1 object.
If it fails, you know that you cannot currently safely access the object
or section.

Ciao, Neil

[Michael]

JDK wrote:
> Alas, Personal is not open.
>
> The files listed in the .cfg are valid. I can open them in Personal
> and I have reorganized them.
>
> Any other ideas?

Could it not be finding the config file that you are passing to it? That
would also trigger this error.

Ciao, Neil

[Michael]

Jim wrote:
> Well that is a good point.
>
> But all users will have current displays of committed data, only
> uncommitted data will be held locally in the volatile file.

Possibly, but it is probably a lot of unnecessary overhead to retain
this in a volatile table, which is a very complex structure, when an
array will probably do the job nicely, possibly with an associated btree
structure for indexed access.

> An option for the detail block could be provided; commit line by
> line, or commit only when told to. This way, the developer/end user
> could choose the case that works best for their situation.

That is worth a thought.

> As for minimizing file access, obviously you want to avoid
> unnecessary disk thrashing or network traffic in your design but you
> can't go too far with that. Most of those decisions quite properly
> belong with the application developer/end user. If you go too far,
> you restrict the usability of the resulting control.
>
> Think C, not Basic. Assume the developer knows what he is doing, at
> least to some extent.

Quite true. I am trying to create something that will give people the
option, not force them into a straightjacket.

Ciao, Neil

[Michael]

Jim wrote:
> As I work on this project of mine, I want to break up the source code
> into a lot of different files and some libraries, and only compile
> what needs to be compiled. If I don't do this, it is going to take a
> LOOONGGG time to recompile whenever I make a change.
>
> However, the "add module" selection for a project does not seem to
> work.

I will have a look. That functionality was added long ago, and I have to
admit it never appealed to me. I tend to compile these sorts of things
as separate libraries/projects. That you can do. Just make sure you
export the function that returns the form, and give it a unique name.

Then add the library to the project.

Ciao, Neil

[Michael]

JDK wrote:
> Two cents or less.
>
> Detailblocks, to me, are first about the DISPLAY of data.

To some degree, I agree with this, but this discussion is intended to
track down what people want from detail blocks, since any decisions we
make here are going to affect anyone using them. I want to keep peoples'
options open as much as possible (that is the job of a tool kit after all).

> So the first thing is the sorting of the children. The data-aware
> grid totally fails at this. For example, if I have a bunch of
> records representing dates that are linked to the master by some
> unique id, I'd want to display that detailblock in date order. Right
> now you can't do that.

The grid component we are using is not a good choice for this sort of
behavior, but when we added it, it was one of the few options available
within wxWidgets. In the interim there are others, but they all require
a significant investment of time and money.

> By the emphasis on DISPLAY I also mean that the adding, modifying and
> deleting of a record associated with a row, I think, needs to happen
> separately via a dialog/form.

Some people do it this way in Superbase, others do it by defining a row
at the top that is not actually part of the block, but which acts as if
it were, and every selection is copied to that row.

> To that end, I always make the detail blocks READ ONLY and I always
> have an "Add" button and a "Modify/Delete" button under the detail
> block. The Add button brings up a dialog/form on which I can add a
> record. The Modify/Delete button brings up a Requester (I suppose in
> simpol a dropdown in a form/dialog) by which one can select
> (sometimes using a search like a drilldown is necessary) a record to
> be modified or deleted (via form/dialog). After all it is often the
> case that you can't show all of the records in detailblock.
>
> So to me, the presence of an Add button and a Modify/Delete button
> really should be incorporated right into the detailblock as a option,
> like a parameter to have a scroll bar or not.

It is one of the options up for consideration, as is the right-mouse
pop-up menu approach (less screen real-estate involved).

> When the detailblock records refer to externals (images or
> documents),I still like using the invisible button. You are really
> not doing anything to the row/record "selected", but are using some
> data in the row/record to open up the image or document (e.g., PDFs,
> TIFFs, BMPs, Word or WordPerfect) in its native program usually via
> ShellExecute.

This could be done by using the double-click support in the onmouse
event for each control. An extra button is not required.

> In the data-aware grids, it's kind of odd that there is no
> onSelectRow event nor an onSelectColumn.

I have them on my internal wish list, but they have not yet been
implemented.

> Think about it. If you click on the row number, all of the row gets
> "selected" or at least it "appears to get selected" because of the
> color change.
>
> The same is true when you click on the column head, the entire column
> gets "selected" or "appears to get selected".
>
> If the entire row is getting selected then should you be able to use
> that to select that particular record.

Actually, I use the oncellselect event of the grid to get that information.

> And if the entire column is getting selected then it seems like it
> should be standard behavior that that would sort the records by that
> field. First click ascending, next click the opposite sort, i.e.
> descending. (Or you could handle it like googledocs spreadsheet.

Sorting is a know requirement, but it also impacts the issues related to
performance. There are only two ways to do this, read all the related
records and then sort them, or allow a link on a partial field value
that is essentially a combined index. Such as linking the master record
ID which might be "00000025" plus the desired sort field and then
allowing a link on the first 8 characters of the target field. I have
considered it, and may yet implement it.

> Just adding these behaviors (OnSelectRow and OnSelectColumn to the
> data-aware grid would make them useful enough to use in lieu of a one
> level detail block. (That and being able to adjusted the size of
> the row numbers, way too wide now.)

As for the row numbers, I am pretty sure you can change them
programmatically yourself, just call the setrowlabelwidth() method I
think it is.

Ciao, Neil

[Michael]

jim wrote:
> "Thinking about it though, there is a real problem with adding
> records, since if they scroll off, how do you reselect them? They
> won't yet exist in the database, so there is no way to add them back
> into the sort order."
>
> Give the detail block the capability to handle virtual rows. There
> will be the physical rows defined by the user on the form, and a
> scroll bar. All uncommitted detail block entries go into an
> appropriately formatted volatile database file, and the detail block
> displays the segment of that volatile database file that is selected
> by the scroll bar on the right.
>
> When the data is committed, the volatile database file is deleted and
> the detail block now shows appropriate entries from the real database
> file – which continues until another change is made, which causes the
> instantiation of a new volatile database file.
>

I suppose it depends on how current the data should be. In a real world
Superbase scenario, if records were added to the data set by another
user, when scrolling the detail block up and down, the new records would
actually appear. OTOH, if we were to make the decision that the detail
block shows a snapshot of the data from the moment of the original read,
then it could work as you describe. What I am trying to avoid is
unnecessary data reads, and creating a volatile table would not
necessarily avoid the issue. I can actually just create an array of
record objects, where the content of the array is any record object that
has been created or modified but has not yet been committed.

Ciao, Neil

[Michael]

JDK wrote:
> After weeks of working fine, I am getting a simpolserver error 7.

Error 7 is data not available. If you have the database open in SIMPOL
Personal, that would do it.

Ciao, Neil

[Author]

Posts