Strange!
I’m getting same problem as Hameed’s loss of style.
Since I couldn’t import my solution as new release , I deleted the solution & imported as new solution using “Import” button. The solution worked fine.
Then I closed the servoy developer & opened it again. The strange thing here is all of my styles got deleted.
Also, I can’t create new style with old style name.
If I create new style with new name ,then it is not shown in editor & also in the form properties.
I noticed that duplicated foundset are modified even if not explicitly overwritten or duplicated again with the same name. I imagine this is not the expected behaviour, and it is in fact different from what happens in Servoy 2.
In a method I have duplicated foundset A and duplicated foundset B which is a subset of A, e.g. A contains 200 records and B contains 25 records from foundset A.
I load foundset A, do a find and obtain a new foundset that I save as B. After this operation, in Servoy 2 foundset A does not change and B is a new foundset, in Servoy 3 foundset A is modified and becomes a copy of foundset B. This happens also if I duplicate foundset A as foundset B before loading foundset B and working on B and saving it again as foundset B: foundset A is also modified.
Hi,
Getting the following error when doing a find in the Servoy editor on everything after pressing “Find” a couple of times to find the xth occurence of the string I’m searching on:
Exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError
at java.util.HashMap.containsKey(HashMap.java:342)
at java.util.HashSet.contains(HashSet.java:182)
at com.servoy.j2db.develop.c.a1.for(Unknown Source)
at com.servoy.j2db.develop.debugger.r.if(Unknown Source)
at com.servoy.j2db.develop.debugger.k.if(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.new(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
at com.servoy.j2db.develop.debugger.a.ab$a.case(Unknown Source)
The last line keeps repeating for hundreds of times.
Haven’t been able to isolate when/why this happens. Could be that it happens after pressing Find after the last occurence or that the search goes into the code of modules (dunno if the search also searches methods of modules)
Paul
Dear Servoyians,
Any idea about the style lose problem during export/import?
This is very important. Currently I cannot move a solution from my developing machine to my testing server. I am just stuck with only my machine. I cannot take my solution to my home computer as well because of the issue.
Please look into this as early as possible.
Thanks a million!!
rioba please add a issue in our support system with a sample solution so that i can look at it.
There is an bug in Servoy 30.rc1 related to style versions, until rc2 (later this week) run after an import on the (import) repository with an SQL tool:
update servoy_root_elements set active_release = latest_release where active_release > latest_release
or with the rawSQL plugin```
plugins.rawSQL.executeSQL(“repository_server”, “servoy_root_elements”, “update servoy_root_elements set active_release = latest_release where active_release > latest_release”)
This is an harmless update, but inconvenient...Thanks Jan!
I appreciate your help.
Hello,
I don’t know if this is an issue with RC1 or a misunderstanding about how foundsets work, but if two forms based on the same table also share the same foundset, then shouldn’t the selected record in each form be the same? I have a related list view in a tabpanel, and a form-in-dialog for editing the selected record in list view. However, the record in the FID isn’t always in sync.
AFAIK, I haven’t done anything to cause the foundsets to be out of sync (no loadRecords fx). I wonder what I’m doing wrong. Or maybe when showing a detail view it’s a better practice to always load the foundset from the list view, to ensure the two foundsets are in sync? Not sure if that made sense LOL.
There is a lengthy/detailed explanation about foundsets in the developer reference guide, my guess is this will help you.
Hi Jan,
I just finished reading that section in the dev guide. I just can’t figure out why they are out of sync since I haven’t to my knowledge performed any function (like loadRecords) to make the foundsets different.
Did you the useSeparateFoundSet property?
Hi Jan,
No, I didn’t select that property. Maybe this will explain my issue better:
Is this expected behavior, given that the two forms share the same foundset?
FWIW, I can certainly avoid this issue altogether by loading the records from the list view form into the detail view form. I was just trying to understand the foundset behavior I was seeing.
please file an support case in our support system with a small sample demonstrating the possible issue, it hard for us to understand what exactly is going on based on a textual explanation
chartpacs:
Hi Jan,No, I didn’t select that property. Maybe this will explain my issue better:
- I have a related list view in a tabpanel that shows 1 record.
- If I simply switch to the list view form itself (using the Window menu), I see the same single record.
- If I switch to the detail view form (again using the Window menu), I happen to see three records. I was expecting to see only the one record.
Is this expected behavior, given that the two forms share the same foundset?
Not sure 100%, but I think related foundset are not broadcasted to other form sharing the same foundset, unless you load the related foundset.
The foundset are shared across forms when you perform a search or do something similar.
Again: I’m not sure it’s still the current behaviour, but I think it worked like that, some time ago.
Hi
I just installed the latest release (Version 3.0rc1-build 365) and get now a new error. Is it possible that you changed the order onShow and onLoad are triggered?
I have a form A which is used in a tab panel of form B. Earlier I found the following order the events are triggered: B.onLoad, A.onLoad, A.onShow, B.onShow. Now I find B.onLoad, A.onLoad, B.onShow, A.onShow. Is this correct?
Questions:
1.) If I’m right: What is the reason for the current order? I miss access to data of form A while initializing B.
2.) Is there an other hook for me where I can do my initialization after all (included) form data is loaded?
3.) Do you offer a sequence diagram for all events to let me understand when they are triggered and what happens during event handling?
Thanks and regards
Birgit
The event fire is indeed changed for onShow, we had some complains that the onShow on a child was called before the parent was initialized. (which did make sense to us)
From Servoy 3.0 it’s uniform now, the parent form always do receive the event first.
So when we have an order form with an sales employees tab, the event order is:
orders onLoad
employees onLoad
orders onShow
employees onShow
–switch to products form–
orders onHide
employees onHide
products onLoad
products onShow
Hi Jan Blok
Thank you for your fast response. I’m glad I found the reason for the errors in my application.
I have to admit that I’m a little confused. Changing this order is quite a change! What if I complain now about the order? Do you change it back?
The old order did make sense to you. So it did to me. And it still does: The last component to be informed should be the parent. From a hierarchy point of view this is the one with the most information (about the children). This component should be the last to do any initialization. And at this point you need the children to be initialized. And not vice versa. What advantage does a child have if the parent is initialized? If a child needs this, hierarchy is wrong. In my opinion.
I’d be very happy if you could think about it again. Please find a useful and clean solution. And please let me know how you decide.
Best regards
Birgit
The old order was never properly defined, the child could not be visible when the parent is not yet visible.
Any parent is more important than it childs (the parent also creates the childs)
Hi Jan
Jan Blok:
The old order was never properly defined, the child could not be visible when the parent is not yet visible.
Any parent is more important than it childs (the parent also creates the childs)
I do not understand what you mean. It sounds as you would agree what Birgit proposes, i. e. that when the parent is more important than the children it should be the last to be informed. With the changes you made in the event execution order it’s just the oposite now, so the parent is less important than the children.
This change is one of series in Servoy which arises for me (once again) the question still not answered, if you intend to support clean OO programming in Servoy and therefore at least not doing things which prevent that (actively supporting OO programming would be even better) or if Servoy is just a better FileMaker tool where Spaghetti programming is standard. Don’t get me wrong, I do not want to offend anyone using any programming style (everyone can do as he/she likes), it is just quite hard if we try to apply OO programming and Servoy is just not meant or intended for that.
I would be happy to hear your thoughts. I also would be very interested to know an example where the previous order of firing events is wrong, as we can not think of any (structured or OO) example in need for that. Obviously, I also vote as Birgit to change back the event firing order to how it was before the rc1 version.
Thanks in advance, Robert
PS: The event firing order is an essential part in Servoy and it would be good if it would be completely published, also taking all the circumstances into account when using modules.