TD 4.1-6.1 issue with check box cells in last row of table

[TerryP]

Hi All,

I came across an issue that appears to be in all versions from 4.1 to 6.1, where check box cells in the last row of a table window or child table don't respond to right click messages (e.g. for context menus).

Attached is an example app (TD 6.1 sp2 Win32) which demonstrates the problem for a table window. If you right click on any cell in any row, the row is selected and the context menu displays. However, if you right click on the check box column cells in the last row, the row isn't selected and no context menu is displayed. It works okay on any other cell in the last row. If you right click on the table area below the last row, no row is selected and the context menu displays.

Test Context Menu on Check Box Columns.zip

The behaviour appears to be the same regardless of whether there's one or more check box columns, whethere or not the check box columns are editable, or their position within the table (first, middle, last). It also doen't seem to matter whether the context menu is processed on the column window or on the parent table, or whether SAM_ContextMenu or VTM_RightClick/WM_RButtonUp messages are being used.

The good news is that the same problem doesn't occur on Grid Windows (and I assume on child grids). The example app includes a Grid Window to show that it works there.

This obviously isn't a major issue, but can be annoying to the user, especially if you only have one row displayed in a table with lots of check box columns!

Cheers,

[Jeff Luther]

Yep, same TW behavior goes all the way back to CTD v1.5. And I got curious if it was an off-by-one issue with wrong row #, so added this to Actions of the Test1 menu:
Call SalMessageBox( 'row #' || SalNumberToStrX( SalTblQueryContext( twTest ), 0 ), '', 0 )

Nope, no problem. I then saw you had the TW Discardable: Yes, but GRID : No, changed TW but no change.

Last, r-click does work -- maybe that's what you described -- on any of the other non-checkbox cells for that last/bottom row. So for some reason last row where column = Checkbox does not get the r-click.

Can you live with this? I'm always fascinated when someone unearths something that's been around for "like forever" but I can add a defect for this issue, Terry. Though it is 'grandfathered in' from long ago and I could not say when dev. would fix this. And as you point out and I see, this is not an issue for the GRID.

[TerryP]

Hi Jeff,

I wondow if it goes back even earlier, but I don't think I'd be able to re-install SQL Windows 5.x 16-bit version to try it out - PC's don't come with 3.5" floppy disk drives any more!

I can't remember coming across this issue being raised in the old Gupta forums, and I couldn't find it when I searched in these forums. I can't believe that it's been around for so long without it being noticed before - and I've been using SQL Windows for almost 20 years now!

Anyhow, I expect it's one of those things, though it would be nice to get it fixed in the latest version (or at least recorded for posterity).

Cheers,

[Jeff Luther]

I wonder if it goes back even earlier, but I don't think I'd be able to re-install SQL Windows 5.x

I thought the very same thing and do have SW v5.0 installed and started to try it there. But... (ah, progress!) but this call:
Call SalContextMenuSetPopup( hWndForm, "menuTest", 0 )

fails. That Sal function hadn't been invented yet, so CTD v1.5 is earliest CTD v1.5 I have where that call is in the product. And same behavior in CTD v1.5.

So, if you are feeling nostalgic or homesick for the 'Good Old Days' here's SQLWindows v5 running on WinXP:

[TerryP]

Hi Jeff,

The SalContextMenu functions didn't exist back then, but you should still be able to try intercepting the VTM_RightClick/WM_RButtonUp message. I'm pretty sure they weren't coming through for the last row's check box cells either in 4.1-6.1.

However, that's all hypothetical and not very relevant now anyway, though there are probably still some 16-bit applications still running. The last one I upgraded from 16 to 32 bit was still running in 16-bit in 2005.

Let me know if you decide to raise the defect to be fixed in 5.2 or 6.x, and I'll keep any eye out for it in the fix lists.

Cheers,