Servoy 5.2.3

Running from developer it does work (did not test application server because it is not running because of my signing issue…)

I have updated the signtester tool with a fix for the “java.util.zip.ZipException: invalid entry compressed size” error.

Get if from ServoyForge: https://www.servoyforge.net/projects/signtester/files

we have the same here… but it looks like it did sign it!

the (latest) signtester says:

Operation aborted due to : java.util.zip.ZipException: invalid entry compressed
size (expected 7909 but got 8103 bytes)
D:\Servoy\Servoy5\application_server.\plugins\scheduler\quartz.jar repacked
D:\Servoy\Servoy5\application_server.\plugins\scheduler\quartz.jar repacked
D:\Servoy\Servoy5\application_server.\plugins\scheduler\quartz.jar signed

Harjo, are you sure you have tried v1.1.1?
I just tried it on the quartz.jar and it signs correctly.

I see that there is a new version of the signtester.jar available on ServoyForge: https://www.servoyforge.net/projects/signtester/files

Could Servoy please update the link on http://wiki.servoy.com/display/tutorials/JAR+signing

I’m experiencing the following error on 5.2.3, and I don’t have the issue on 5.2.2 or previous versions

  • I start a transaction, add a record to the table, and then I click on my save button, which will commit the change
  • I have an onRecordInsert on a table that will populate some fields ==> The changes on this global method seems not to be using the same thread of the form where the transaction just start. The error log shows the following error:
    “…Thread tried to acquire lock which is already owned, transaction id=0, thread=http-8080-4”

Hi Patrick,

Thanks a lot for the update of the signtester !

Regards,

ptalbot:
Harjo, are you sure you have tried v1.1.1?
I just tried it on the quartz.jar and it signs correctly.

No, at the same time I replied, there was a new version :-)
will try & test this weekend! thanks for quick response…

jvalencia:
I’m experiencing the following error on 5.2.3, and I don’t have the issue on 5.2.2 or previous versions

  • I start a transaction, add a record to the table, and then I click on my save button, which will commit the change
  • I have an onRecordInsert on a table that will populate some fields ==> The changes on this global method seems not to be using the same thread of the form where the transaction just start. The error log shows the following error:
    “…Thread tried to acquire lock which is already owned, transaction id=0, thread=http-8080-4”

jvalencia,

This issue is already discussed in this same thread.
We have fixed this in 5.2.4 which will be released soon.

Rob

TYPE_AHEAD issue
On 5.1 works fine, on 5.2.2 works partially, and 5.2.3 doesn’t work on the table view, and partially on the record view.
I’ve attached a sample so you can try and see the differences
Thank you!

Issue_Type_Ahead.servoy (5.75 KB)

jvalencia:
TYPE_AHEAD issue
On 5.1 works fine, on 5.2.2 works partially, and 5.2.3 doesn’t work on the table view, and partially on the record view.
I’ve attached a sample so you can try and see the differences
Thank you!

I have quickly tested your solution in Smart and Webclient and with both i dont see any problem

I can create a order record just fine by pressing the first button (and then i can choose the customer just fine)
then i press the second button that creates a order_line and there i can choose the product just fine from the list that pops up

TYPE_AHEAD issue

The list on the table view shows the id, and the description
On 5.1 you can type numbers or letters and the menu will short the options as you type
On 5.2.2 you can type numbers but no letters
On 5.2.3 shows the menu but the menu doesn’t adjust to what I’m typing
I’ll try 5.2.4 and see what it happens

Thank you!

jvalencia:
On 5.2.2 you can type numbers but no letters

Yes this was a bug and is fixed in 5.2.3+

jvalencia:
On 5.2.3 shows the menu but the menu doesn’t adjust to what I’m typing
I’ll try 5.2.4 and see what it happens

in this area 5.2.4 should be the same as 5.2.3
But if you type fast then i guess it works. but if you type slower so first 1 char wait wait and then 1 more char the list is empty?

This is because we search then in memory on 1 string that is displayed instead of doing a like search on the database on 2 columns
Will see if i can improve this so that in memory behaves more like the database.

If you have 2 columns appended like you have in your example

column1 column2

then we generate a like on both:

elect distinct productid, productname from products where upper(productid) like ? or upper(productid) like ? or upper(productname) like ? or upper(productname) like ? order by productid asc, productname asc limit ?

so you get hits on both

but if we then have the list in memory and we know the database doesn’t have more then we start searching in memory on the con catted string… so you can suddenly no hits if you only hit the column2

The thing is what is really what we want if you append columns like that the user doesnt know we do a like value% so it should start with it.
is it logical that you get results from the database like that hits only column2? Because currently the typeahead behaves more like “like %value%” when looking in the ui…

EDIT: What database did you have when using 5.1 and which one on 5.2? Do you have something in your log?

we fixed the problem (for for example postgresql) when you had a valuelist on a none string column that you use in the typeahead.
Also i made the in memory search and the database search more in sync with each other so that they behave the same.

Jeff,

We found the issue using a sample.
The key thing appeared to be that the login form was extending another form.

This will be fixed in 5.2.7.

Rob

jbader:
security.login no longer forwards to first form even when returning true

5.2.3, not using enhanced security and using a custom login form.

Any ideas? What do I need to do? Manually show the form after security.login?