New event: OnRecordClicked()

OnRecordClicked() would fire when the user clicks on a record.

This would eliminate lots of extra code, global flags and/or buttons necessary to differentiate between OnRecordSelected because a user clicked on a record in a list view, versus OnRecordSelected triggering ‘on its own’ in response to other events.

Jerry,

What would qualify as a “click”? Click on an object? Click on the body? Click on the header? Click on the footer?

I don’t get how this is better/different than when you change records.

Click on the body. This is primarily for Listviews in tabless tab panels intended to allow the user to select a single record from a displayed (separate) foundset.

This goes back to the discussion you and I had about a week ago. You suggested you get around this by using OnRecordSelect to show the user additional information about the selected record in a box near the listview, and having a single button in that box that actually selects and loads the record into the detail view.

You indicated you do this for two reasons: (1) its nice to give the user the addtional info about the record they’re about to select, and (2) you, also, need a way to get around the automatic triggering of OnRecordSelect in circumstances other than the user actually clicking to select the record.

While I like and appreciate your solution in some cases, I’m finding many more where I don’t want the extra step of displaying additional info and giving the user a button. I want them to be able to select a record just by cliicking on the record in the tabless tabpanel listview, and to have their manual selection trigger an action. I find this action is virtually always a different action than the one I want triggered when a contextual change, rather than a user click, triggers the OnRecordSelected.

Since you can’t use the old Filemaker trick of putting an invisible ‘button’ over the entire record body (since this results in to put it mildly, aesthetically unappealing behavior) and you can’t use OnRecordSelected (easily) to trap a user click because it triggers on lots of events other than the user selecting a record by clicking on the record body, we don’t really have an elegant solution to this (IMHO) ubiquitous issue.

What I’d really like is a boolean property that could be tested within the OnRecordSelected event, something like OnRecordSelectedManually.

// This is the OnRecordSelected Method

if (OnRecordSelectedManually)
{
   ...do stuff...
}
else
{
   ...do stuff that should only happen on non-manual select...
}

...do stuff that should happen regardless...

// End of Method

This would keep the simplicity of only having one event, but would allow differentiation between the two very different ways that event can be triggered.

I would say that we need an onRecordAction event that is triggered when a the user either:

  • hits the Enter/Return key on the Keyboard
    OR
  • doubleclicks with the left mousebutton on a record

This second option would behave as follows:

  • When the mousecursor is hovering over a selected record, the event is fired after the second click
  • When the mousecursor is hovering over a not selected record, The first click selects the record, the second click fires the OnRecordAction event

This event, imho, should be available on

  • ListViews,
  • Tableviews,
  • Portals

This event is, I think, when a user would expect to be there.

Paul

That sounds great. Much more in keeping with the current event structure!

Mmm, I realise that the discussed event is in conflict with selecting the content of one of the fields. When the field has focus, double clicking it will (de)select the content of the field.

To take away the conflict, I think that if an onRecordAction event is attached, the fields in the list of records should all enabled, which means the user also cannot select the text.

Just thinking here… This would give us a datagrid like you see in many applications…

Paul

I would love to see this features too!

I now simulate the doubleclick with this: http://forum.servoy.com/viewtopic.php?t=2807&start=0

It works, but Enter and Return does not do anything.

Is there any chance this will be implemented ? (soon ?)

It is realy a pain to make unrelated tabs, forms, work toghether without knowing which record was selected by the user. ( and not by any other servoy function or event )

Even the double click solution will not work, since you can only select a record once ( even if you click it 100 times. )

Is there anybody that has a workaround that works with tab panels and forms ( not HTML ) ?

Not entirly an answer to your question, but are youaware of the ability to add tabs to a tabpanel at runtime WITh a relation? (possible as of Servoy 3.0)

Paul

Hello Paul,

No I was not aware of this. It looks like I still have to grasp a lot of the new possibilities built in version 3. At the same time it is also putting me for the chalenge to re-write, re-work a rather large existing solution I’m currently building.

I will look into this, if this will help me, I’ll let you know.

By the way, will this also work between related forms based on views ?

Can’t see why it wouldn’t work for forms based on views…

Paul,

I have tried to create related forms in tab panels dynamically, but somhow this does not work to me.

I may have come to conclusions too soon, and I will ofcourse search and test further but maybe you can explain a bit to me how you can set up these dynamically added related forms to a tabpanel.

These are basically my questions :

  1. Do you relate 1 to many ( parent to childs ) or the other way around
  2. If you relate downwards (parent to childs) but the main form has a dummy form in one tab_pannel that contains your childs and grandchilderen how do you set the related foundset of the top level of all these childeren.
  3. How does this relation apply to a foundset on a form that has the useSeperateFoundset marked

if you are interested in the actual situation than here is some more info :

My relations are :

one ‘special handling’ document (record) can have [0..1] prepack_manual
one ‘prepack manual’ (manifest) can have [1..x] boxes
one box can contain [1..x] styles
one style can have [1..x] sizes

I have relations :
sh_to_manifests
manifests_to_boxes
boxes_to_styles
styles_to_sizes

(It is more complex than this since each level has other relations as well, but this is the essence I want to accomplish right now. )

My servoy form layout is more or less as described in the attached image. So basically it is a main form where optionally an extra tab can be added that will show a related form. This related form is based on the related manifest form, and contains a multi purpose tab, in one of the conditions this multi purpose tab ( tab_main_workspace) can contain a form based on a dummy table, that holds the last three related tabs with their forms : boxes, styles and sizes.

But when I add the forms to their tab pannel with the addTab comment and use the related foundset I get an errormessage : java.lang.ClassCastException : com.servoy.j2db.dataprocessing.x

In the documentation they use forms.orders as form and forms_to_company as relating foundset.

Which made me think I had to set my relations the other way around from the multiple ‘child’ records to their single ‘parent’ if you like.
So I created sizes_to_styles, styles_to_boxes, boxes_to_manifests, and tried it like this, but with the same result (same error)

I used seperate foundset before and global fields to keep track of the selected records, and used the selectedrecord event to trigger a find on the “child” forms, but now I switched of the seperate foundset, I’m not exactly sure how the relation works on forms with seperate foundset switched on. But I guess it will not keep this one in sync. ( showing related entries only )

Can you tell me what I’m missing here. If the relation is downwards, than how do you start with the first one ? I’m a bit puzzeled all toghether on how this works I guess.

Hi Paul

Happy to see that one can dynamically load a tabpanel also for a related form. I (tried) to use it for a tabless tabpanel. But when I load the form, I get ALL related records, whereas I expect to get only the ones related to the selected record, i. e. I expect the same behaviour as if I would do it “statically” by placing a tabpanel to a tabless panel. Otherwise it’s quite useless, is it? So to me it seems to be a bug.

Best regards, Robert

PS: May be this is at the end the same effect as descibed by Zac.

pbakker:
Can’t see why it wouldn’t work for forms based on views…

Hi All

As I just noted, you added the iconURL parameter between (in the previous v2 version exisiting) parameters. Doesn’t that mean that one has to change all existing statements?
And in the example in Servoy3DevReferenceGuide.pdf on page 297 (or 305 in PDF counts .-) you have this parameter omitted. As the example uses the optional relatedfoundset parameter, it should have 8 parameters, but only has 7.

Also the text on page 121 should be adjusted for the relatedfoundset possibility.

Best regards, Robert

Happy to see that one can dynamically load a tabpanel also for a related form. I (tried) to use it for a tabless tabpanel. But when I load the form, I get ALL related records, whereas I expect to get only the ones related to the selected record, i. e. I expect the same behaviour as if I would do it “statically” by placing a tabpanel to a tabless panel. Otherwise it’s quite useless, is it? So to me it seems to be a bug.

Tried to reproduce this, but can’t. Whether a normal or a tabless tabpanel, if I dynamically add a tab at runtime and specify a relation, the form in the tabpanel shows only related records to the selected record in the main form.

If your problem persists, please create a samplesolution and a case in the support system.

Paul

As I just noted, you added the iconURL parameter between (in the previous v2 version exisiting) parameters. Doesn’t that mean that one has to change all existing statements?

No, existing code does not have to be altered. The system recognizes the type of parameter.

Paul

Zac,

I think, based on your scenarion, you don’t need a dummy table, or use separate foundsets.

You need to create the following sturcture in forms:
sh form containing tab with:
manifests form containing tab with:
-boxes form

  • second boxes form with a tab showing the styles form
  • third boxes form with a tab showing a second styles form showing a tab with the sizes form

If you nest this way and keep using the same foundset, all relations will cascade downwards properly. If you feel something is not working as it should, please post a sample solution.

The java.lang.ClassCastException : com.servoy.j2db.dataprocessing.x should not occur if the system is used properly.

Paul

BTW: relations are created from parent to child, not vise versa