Newbies questions, multiple windows? record-level events?

Classic Servoy
1

I’m evaluating Servoy to replace an aging Filemaker solution.

So far, I haven’t been able to identify two abilities I’d like to have, from a developer perspective. Perhaps someone could let me know for sure if they aren’t there, or I’m just missing them…

First is multiple windows. Yes, I’ve seen .showFormInDialog, and I can probably make that work for most of my needs, but users would really like to be able to multiple instances of the same form open at once – ie, viewing different found sets. Is this possible?

Second is CRUD events on the record level, not the form level – ie, onInsert, onUpdate, onDelete that are attached to the tables rather than the forms, so if you use the same tables in multiple form they will still be fired without having to worry about hooking up the right methods in both places. Auxilary to that would also be field level events, so you didn’t have to worry about hooking up to the controls. Does this exist? Or is it possibly being considered for future versions?

Thanks for the info.

greg.

2

Hi greg,

Welcome to Servoy,

thegregor:
First is multiple windows. Yes, I’ve seen .showFormInDialog, and I can probably make that work for most of my needs, but users would really like to be able to multiple instances of the same form open at once – ie, viewing different found sets. Is this possible?

Forms based on the same table can either share a foundset or be independed. I don’t think you can have the same form showing more than once, but you could duplicate the form to get around this.

thegregor:
Second is CRUD events on the record level, not the form level – ie, onInsert, onUpdate, onDelete that are attached to the tables rather than the forms, so if you use the same tables in multiple form they will still be fired without having to worry about hooking up the right methods in both places. Auxilary to that would also be field level events, so you didn’t have to worry about hooking up to the controls. Does this exist? Or is it possibly being considered for future versions?

In other words you’d like to use constraints/triggers/rules in your SQL database… rather than have to worry about these issues on every screen in your front end…

I have experimented with triggers in PostgreSQL, mainly to gather data to enable fast reporting. If you do change data outside Servoy, the current version of Servoy will not know about the change until you restart it. Version 3.0 will have a new plugins to get around these issues

If you add constraints to your database, and your Servoy user violate them you currently get an Can’t save/Can’t Delete etc error message.

Meanwhile, you can write global methods that you attach to your forms to deal with most data consistency issues. Servoy allows you to write some very reusable abstract methods. Once you have a good set of methods, you can put them in a module and use them for all your projects.

Coming from FileMaker, you may find it takes a little while to really exploit the Servoy architecture.

From my own experience:
A couple of months ago, I had to create 7 global variables and duplicate 8 form methods per table, and hook them up to get my reusable user-interface working. I was not happy about the dulication, but I could still create stuff faster than in FM6/7.

After some interesting sessions at Servoy World, I have rewritten my core module so I can achieve the same result with no global variables and no new form methods. I only having to hook up one global method… :slight_smile:

Servoy allows you to many things you’d never dream of in FM…

Good Luck,

3

In other words you’d like to use constraints/triggers/rules in your SQL database… rather than have to worry about these issues on every screen in your front end…

Well, no, not really. I like to have a logic layer between the database and the UI for consistency. I was going to write this app in .NET, but as I’ve moved forward with it I’m really going to need a more RAD environment to get it done in a reasonable time frame.

Servoy looks great. I pretty sure I’ll be able to accomplish what I need to as I get more familiar with it. It’s also a great option because the user base of this app is familary with Filemaker and there are some similarities that will make it an easier transition for them.

I’m more from an Object Oriented background then a Filemaker one, though, so I’m trying to look for ways to get a cleaner seperation between my logic and the UI. It’s probably just me needing to get in the right mindset for Servoy.

I’m very impressed with Servoy’s simplicity. I’ve been making a lot of progress in a very short time. :-)

4

Hi Greg,

Multiple windows other than via a form in dialogue is not available now.

Whether it will be in future versions is also unknown - by me anyway !

Forms with tab panels have been used to great effect to ‘spoof’ multi window environments because we can programmatically control their visibility etc and also the form in dialogue command can be ‘stacked’ to allow you to navigate multiple windows (forms) within a single dialogue window !

Not the ideal solution for you but perhaps it is worth identifying specific instances so someone can offer advice on how they did it !?

Regarding table based triggers - as each form is based upon a table you can create methods specific to that table and then add these to the form properties available per form which are for example : onNewRecord, onSearch, onDelete, onRecordSave etc etc etc.

You do have to attach the same method to each form (ergo table) but this is your only option at the moment unless you use triggers within the database itself !

Perhaps NOT what you wanted to hear but we are working within the SOM heirarchy which these resolutions fit neatly into !

Not sure about further into the future but, unless the Servoy dudes say otherwise, I cannot see this base situation changing !

Cheers
Harry

5

Servoy uses a Single Document Interface per:
http://forum.servoy.com/viewtopic.php?t … +interface

6

As everyone knows, we take all suggestions form our developers seriously.
However, convincing us to implement them may sometimes be hard :wink:

We think a single window interface is a much cleaner approach.
Workflows are much more controlable and organised.
In case you do need simultanious multiple info, recordsets etc. , this can all be done with (dynamic) tab panels.

But again, if you think you do have a situation that can’t be done properly in Servoy, let us know.

7

I agree with what Maarten says that in most instances it is much cleaner to have a single user interface (with perhaps different tabpanels accessing the same table for different ‘looks’) rather than have multiple ‘windows’ open accessing the same tables. However if for some reason your users need to keep a separate ‘base’ window open keeping track of something or other on the same table that they are working on, there is one other way of doing that with Servoy. Providing there doesn’t need to be any interaction between those ‘windows’ then you can have two separate Servoy clients on the same machine accessing the same Servoy solution (or separate Servoy solutions for that matter) which are based on the same SQL backend table.

8

i can’t really commit to this yet that it all will make in 3.0 but

1> forms can be reused and used/displayed at the same time by using aliases. So giving the same form more names that you can use to show it in a form dialog or in a tab. (So duplicate form is just duplicate name :))

2> I hope to improve Form in dialog in 2 ways, 1 really be able to stack them so the previous form dialog says visible and the script that opens the second one will block. And maybe 2 (but currently i don’t thing this will make it) you can choose if a form in dialog is modal or not.

3> Also on the planning is that you can define more things on the table level. So attach a validation script to a column. Or maybe like suggested above attach a script to a table for delete/insert/update

9

WOW!

Sounds fantastic Johan! Two thumbs up!

Paul

10

oh yes, PLEASE! :D