david:
[new] function setBorder is added to all form elements to change a border at runtime
this function only works once. is this the intended functionality? i don’t see any use for it unless you can change border properties on the fly (which i’ve wanted forever!).
With setBorder you can change the border (with all properties) at runtime. You just have to call the method with the string that appears on Properties Panel → borderType. So just find in designer → editing mode the border that you want; copy the exact string as it appears there and call setBorder with that string. This way the border will be changed at runtime with the look you found in editor.
it would be nice to be able to use this function to highlight the current cursor field for example. which means this function needs to work over and over.
Changing UI properties is not supported by Servoy, its at your own risk, changes are not visible in web for example, its considered UI hacking. (we only allow you to change properties if you know what you are doing)
david:
yea but you can only run this function once…
it would be nice to be able to use this function to highlight the current cursor field for example. which means this function needs to work over and over.
i don’t see any uses for just calling it once.
setBorder should work everytime
It should change the border constantly.
my guess then is that this is a platform/java dependent function. i just updated to the latest mac 10.4.11 and now no matter what string you put in for the border property the border on a text field is changed to a line border. it was setting the border property correct (one time only) before i updated.
also, setting the border of a button disables the onAction event for the button. again, maybe only a mac issue.
svroemisse:
[fix] background color not honored for header body parts
This fix is only working correctly for me in Developer, not in Client mode. This is a problem even though I’m setting the color of the form through a style, as well as attempting to set the color of the header via the background property.
Attached are three screen shots to illustrate the differences that were caused by upgrading to 3.5.4. I think along the way on this thread my point got lost. Harjo seems to be suggesting a fix for me – but I’d have to go make sure every combobox and checkbox (and i bet radio button) in my solution is classed to this new class, I think. Help?
I again think this was caused by a fix I requested to comboboxes that is in the release notes for 3.5.4 which I need – there are in fact five fixes I requested in 3.5.4 but I can’t deploy 3.5.4 in production until this gets fixed.
Thanks Servoy for your attention to this matter. I submitted it in your issuetracker but it’s still marked new. Hope I can clear things up with these screenshots.
ellenmeserow:
Attached are three screen shots to illustrate the differences that were caused by upgrading to 3.5.4. I think along the way on this thread my point got lost. Harjo seems to be suggesting a fix for me – but I’d have to go make sure every combobox and checkbox (and i bet radio button) in my solution is classed to this new class, I think. Help?
nope, just create the class: combobox in your style.
like this: combobox {
//do your styling here
}
the same for the checkboxes:
check {
//do your styling here
}
you dont have to apply this to every combobox or checkfield.
You only have to apply the style to the form.
The issue with the styles for “check” & “combobox” has been changed, so if you have no style specified for them, Servoy will use the style for “field”, like before;
you can wait for the next release with the bug fix, or create in your css, two new styles, “check” & “combobox”, same as for “field”
svroemisse:
[fix] background color not honored for header body parts
This fix is only working correctly for me in Developer, not in Client mode. This is a problem even though I’m setting the color of the form through a style, as well as attempting to set the color of the header via the background property.
Potentially disregard this…I swear this was happening yesterday on multiple clients, but no longer seems to be an issue today.
ellenmeserow:
Attached are three screen shots to illustrate the differences that were caused by upgrading to 3.5.4. I think along the way on this thread my point got lost. Harjo seems to be suggesting a fix for me – but I’d have to go make sure every combobox and checkbox (and i bet radio button) in my solution is classed to this new class, I think. Help?
nope, just create the class: combobox in your style.
like this: combobox {
//do your styling here
}
the same for the checkboxes:
check {
//do your styling here
}
you dont have to apply this to every combobox or checkfield.
You only have to apply the style to the form.
It would be great to have also this possibililty for radios
radio
{
// styling
}
radio.myField
{
// another styling
}
[fix] support for multiple constraints between two tables when creating relations from foreign keys
I have used this now, and think a slight tweak is in order…
Right now, when one table has multiple keys back to another table, foreign key names are being created as integers e.g. company_to_address_1, company_to_address_2, company_to_address_3 etc. But wouldn’t it make more sense to actually use the fk name or column name instead of incrementing an integer and munging?
By incrementing an integer and using that for a name, I am forced to delete the relationships that were created for me (and rename them) because I cannot easily refer to them programatically without referring to the relationship itself and figuring out what columns are in the relationship. If the column names or the actual fk name was used then names would be descriptive and could be referred to programatically easily.
“fk_company_to_address_2” makes no sense to me where as
“fk_company_to_address_bill_to” or “fk_company_to_address_ship_to” does.
I see your point, these relation names are not very descriptive.
However, the problem with using the FK name is that it already used for the opposite relation.
The problem with using the column names is that you will get very long relation names (for example orders_orders_id_to_order_details_order_id).
Regarding using the FK name, it would make sense (to me) to use it, but then tack an auto-incremented integer to the end of it. So a back relationship may end up with fk_carton_to_human2…etc.
That would be a lot better than a non descriptive relationship IMHO.
Another option would be a prefix for the back relationships e.g. bk_fk_… or something
