A recent question on the Revelation Forum asked how to detect an ENTER keypress when using an EditTable as this is not exposed by the standard OpenInsight CHAR event (ENTER is one of the keys that the EditTable normally considers to be "reserved" like TAB and the Arrow keys).

Despite this limitation it is actually possible to detect an ENTER keypress with WM_KEYDOWN window message and the WINMSG event but ONLY if the EditTable is set to "Protected", i.e.




To trap the ENTER key we first need to tell OpenInsight that we want to be notified of any WM_KEYDOWN window messages that are sent to the EditTable by using the OpenInsight QUALIFY_EVENT message. This is normally done in the form's CREATE event:




Once we've done this we can write a WINMSG event handler for the EditTable that responds to the VK_RETURN keycode:




(Note in these examples we are using some insert records from our WinAPI Library that you can find here)

Labels: EditTable, EditTable Cookbook, OpenInsight

Following on from our recent post on how to remove the row-selection from an EditTable we came across a related issue last week that we think you might like to know about.

Basically we designed a form with several EditTables, all row-select enabled, but during testing it became difficult to know where the actual input focus was as so many controls had a selection highlighted. We could have used the technique in the aforementioned blog post to clear the row-selection during the LOSTFOCUS event, but in this case we still needed to see which row was selected even though the focus was on another control.

The solution we used was to change the highlight color of the EditTable during the LOSTFOCUS event, toning it down to a lighter shade than normal. We then reset it during the GOTFOCUS event. This is actually quite easy to achieve with the COLOR_BY_POS message, the only real challenge is to devise an algorithm to fade the highlight color.

As usual we've saved you the trouble - here's small function that you can use as a starting point for your own application should you wish to use a similar technique:



In your EditTable LOSTFOCUS event you call this:




And to reset the colors in your EditTable GOTFOCUS event you call this:




(You'll notice that the function uses two "WinAPI" $insert records, both of which can be found the WinAPI Library that we recently posted.)

You can download a text version of edt_FadeSelection here.

Disclaimer

Labels: EditTable, EditTable Cookbook, OpenInsight

There's a quick way to select or deselect all rows in a multi-select edit table, and that's via the DTM_SELALLROWS message. It takes a single wParam argument which is TRUE$ to select all rows, or FALSE$ to deselect them.

Here's an example:

Labels: EditTable, EditTable Cookbook, OpenInsight

One of the more annoying visual traits we find with the EditTable is with single row selection: There seems to be no way to unselect a row and remove the highlight once it's there, and this can lead to a confusing state when it appears that more than one control has the focus.

We've often been asked how to rectify this as simply setting the SELPOS property doesn't suffice, so here's the solution - we use the Windows API SendMessage function to clear the selection like so...

Labels: EditTable, EditTable Cookbook, OpenInsight

Way back in the days of OpenInsight 7.2.1 the EditTable was modified so that the speed of setting large amounts of data via the LIST or ARRAY properties was significantly increased.

What was not changed was the speed of getting data via LIST or ARRAY and this can have a impact on the setting speed if you're not careful, because each Set_Property operation performs an implicit Get_Property regardless of whether or not you actually want the original data.

For example, if you already have 10000 lines of data in your EditTable and you want to use the LIST or ARRAY property to set new data you may still see a speed drop as the system uses the slow Get_Property to retrieve the original data before the update.

To overcome this problem you can tell the EditTable to clear the existing data before you use Set_Property, that way the implicit Get_Property has nothing to process. This can be done with SendMessage() and the DTM_RESETDATA message like so:

Labels: EditTable, EditTable Cookbook, OpenInsight

Getting notification of mouse messages has always been something of a problem with OpenInsight EditTable controls. With other controls this process is quite easy - you simply qualify the WINMSG event with the relevent mouse message number and you can easily respond to it, but with an EditTable this process fails.

This is mainly due to the architecture of the EditTable itself - it's not really a single control, it's actually two: The visible control that you interact with (known as the "DataTbl" control) and a very thin parent wrapper around it (called the "Editable" control).

When you use an EditTable control in your application OpenInsight creates the wrapper control which in turn creates the visible "DataTbl" control. When you interact with an EditTable in Basic+ you are interacting directly with the wrapper - it simply passes on your request to the "DataTbl" as appropriate. If you qualify the WINMSG event on an EditTable you are qualifying against the wrapper - you are NOT qualifying against the visible "DataTbl" control!

When the user interacts with the EditTable control they communicate with the visible "DataTbl", so it is this part that receives the mouse messages. These messages are interpreted and the relevant notifications passed up to the wrapper and then onto OpenInsight - they are not passed directly, so you will never be able use a WINMSG event with the usual mouse messages.

However, since OpenInsight 9.1 it has been possible to trap mouse messages by another means. In this version, when the "DataTbl" receives a mouse message, it actually sends a notification message to the wrapper that you can pick up with a WINMSG event. The mouse message itself is simply offset by the value 3124 (WM_USER + 2100).

For example to detect a "Right Mouse Button Down" message you would qualify against WM_RBUTTONDOWN + 3124 like so:

Labels: EditTable, EditTable Cookbook, OpenInsight

A common requirement when dealing with EditTables is to prevent a user from deleting a row on a case by case basis at runtime. In many applications we've seen this implemented by trapping the standard DELETEROW event and then sending an INSERT message with the deleted row contents, but this looks messy and unprofessional because the data disappears and reappears again.

A better way to do this is to trap the low-level ETM_DELETEROW notification sent by the EditTable prior to the actual DELETEROW event occuring. However, this notification has to be handled in a synchronous fashion (via a WINMSG event), and we also have to tell OpenInsight to return a special value from its own low-level internal message handler so that the EditTable stops the deletion (This last requirement is why the event has to be handled synchronously, because we need to return a value at the point in time that the message is sent).

We do this in two stages: First we tell OpenInsight to trap the WINMSG event for the EditTable and listen specifically for the ETM_DELETEROW message. This is normally done in a form's CREATE event like so:



Next we have to add a WINMSG event handler to the EditTable to catch the ETM_DELETEROW message:



Set_WinMsgVal

Notice the use of the Set_WinMsgVal function. This function only works from within a synchronous WINMSG event and it allows us to set the actual low-level value that OpenInsight returns internally from handling the ETM_DELETEROW message. Returning 0 here tells the EditTable not to allow the row deletion.

Preventing Row Insertion

We can also prevent users from inserting rows in a similar fashion, by trapping the ETM_INSERTROW message instead (which we've defined in the examples above). However, implementing this is an exercise left for the reader.

Labels: EditTable, EditTable Cookbook, OpenInsight

Still on the topic of undocumented EditTable features here's the details of the MOVE_ROW message that you can use to move a row within an EditTable. The nice thing about this message is that it takes all the colour, style and formatting information when the row is moved, which makes it easier to use than deleting and inserting the row "manually" yourself.

MOVE_ROW message


E.g.

Labels: EditTable, EditTable Cookbook, OpenInsight

As documented the TEXT_BY_POS message may be used to retrieve the contents of a nominated cell. What is not documented is the fact that you can use it to update the contents of a cell as well. It's simply a matter of adding an extra parameter containing the data you wish to set.

E.g.



OpenInsight trivia bonus: The EditTable CELLPOS property is a simple wrapper around the TEXT_BY_POS message.

Labels: EditTable, EditTable Cookbook, OpenInsight

While recently adding a new window into our internal admin system we ran into a subtle problem with the CHANGED event and the NOTIFYPOS property.

NOTIFYPOS is an EditTable property that is always updated to contain the coordinates of the last cell to raise an event, but this is not restricted to the CHANGED event: Any EditTable event that is cell-oriented will also update NOTIFYPOS when triggered, common examples being DBLCLK and POSCHANGED.

In our case the sequence of events ran like so:

1. The user edited data in a cell and hit the down arrow to move to the cell beneath.


2. The EditTable registered that the data had changed and set NOTIFYPOS to the edited cell position.


3. The EditTable raised a CHANGED event.


4. The EditTable registered that the cell position had changed and set NOTIFYPOS to the position of the 'new' cell.


5. The EditTable raised a POSCHANGED event.


6. The Basic+ event handler for the CHANGED event executed - but now NOTIFYPOS was pointing to the 'new' cell, not the edited one - and our code mangled the data!

Now you'd think that step (6) would actually have taken place straight after step (3) but unfortunately that's not the case due to the way that OpenInsight communicates with OpenEngine to run Basic+ event handlers.

Normal Basic+ event handlers are executed in an asynchronous fashion, i.e. they are not executed directly when the notification is received, but are placed into a queue and executed when the queue is processed by the application's "message pump" (For those of you familiar with the Windows API they are dispatched via the PostMessage function).

The solution to the problem was to ensure that our Basic+ event handler ran in a synchronous fashion instead - i.e. it should be executed as soon as OpenInsight is notified by the EditTable that the CHANGED event has taken place. That way we know that NOTIFYPOS will still contain the correct coordinates when our handler runs.

Doing this was simply a matter of qualifying the CHANGED event with the synchronous flag in the window CREATE event handler like so:



The new sequence of events now ran like this:

1. The user edited data in a cell and hit the down arrow to move to the cell beneath.


2. The EditTable registered that the data had changed and set NOTIFYPOS to the edited cell position.


3. The EditTable raised a CHANGED event.


4. The Basic+ event handler for the CHANGED event executed


5. The EditTable registered that the cell position had changed and set NOTIFYPOS to the position of the 'new' cell.


6. The EditTable raised a POSCHANGED event.

Labels: EditTable, EditTable Cookbook, OpenInsight

Many of the applications we write need to display things like option dialog boxes near a specific control. In most cases this is quite easy to handle as we can easily obtain the SIZE property of a control and work out our positioning from that. A slightly more difficult task is to position something relative to an EditTable cell because OpenInsight doesn't expose this information as a property or a method.

We've seen many attempts to calculate cell coordinates in Basic+ - we've even done it a few times ourselves and it's quite a pain, having to take into account all the different styles of the edit table, the width of columns, which columns are hidden and so forth.

Well, there's a really easy way to do this, and that's by asking the EditTable itself what the coordinates are via the standard Windows API SendMessage function. We just need to know what message to send to the EditTable.


DTM_READCELLRECT

The message we need is called DTM_READCELLRECT, and it returns the coordinates of the cell identified via the ACCESSPOS property. All we need to do is pass it the address of a RECT structure to fill in, which we then translate into a dynamic array which we can use further.

Here's a simple function to demonstrate this:



(The more pedantic amongst you may notice that we didn't reset ACCESSPOS after we updated it. The reason for this is simple - every low-level function in the EditTable updates ACCESSPOS to the required coordinates before executing, and you should never assume ACCESSPOS is at the correct coordinates - always set it yourself before use!)

You can download a text version of edt_GetCellRect here

Labels: EditTable, EditTable Cookbook, OpenInsight