I have some news regarding the plugins on the ServoyGuy site. Below is a list of updates.
1. I have updated the SpellCheck Pro plugin so that it is working in 4.x, and fixed the problem with TEXT_AREA and HTML_AREA field types. More info at: http://www.servoyguy.com/servoy_compone … pro_plugin
UPDATE: 6/28/2010- We have migrated all of our open source plugins to ServoyForge.net in an effort to help build the open-source Servoy community
Thanks a lot Scott, you rule!
This open source multi-release is one of the best thing that could happen with Servoy being more and more used by Java developers.
That’s a very good idea, and I think that everyone (you included) will feel the benefit of it one day or another: IMHO more people able to support components like yours, mean more robust tools to build better Servoy apps, which means happy end users and good business for everyone!
The next best thing would be a major upgrade of the documentation, and Servoy would be on its way for a wider java (world?) adoption!
Let us all make a prayer and hope the gods will hear us
Yes Scott this is great news.
Sadly the robot seems to be missing. I assume it is still proprietary and non-releasable? Or the other 3rd party plugins do a similar job?
Robot plugin was internal /non-public code that couldn’t be released. In addition, it has been discontinued. Instead use the User Manager plugin from Patrick: http://servoy-plugins.de/plugins/userma … lugin.html
Just a quick note to inform anyone interested that I fixed the busy plugin this week-end.
It was breaking the web client when used (and even when not used, just sitting in the /plugins folder) because of the way it was trying to get a handle of the application’s main Frame (a Swing object, which doesn’t exist in a browser).
I committed the cleaned-out code to the google code project and made a release of the jar for easier download.
You can find it here: Google Code Archive - Long-term storage for Google Code Project Hosting.
I also found this free plugin from Mindfire which seems to work similarly.
Haven’t tested it yet (only found it yesterday).
Thanks a lot, Scott.
A little feature request: do you think is possible to make busy plugin “busy cursor” feature also work with form in dialogs?
Riccardino:
Thanks a lot, Scott.
A little feature request: do you think is possible to make busy plugin “busy cursor” feature also work with form in dialogs?
It should be possible, anyway the plugin right now uses a deprecated method that should really be replaced by another implementation, I will have a look.
I have added support for dialogs (FID) for the busy plugin, and got rid of the usage of the deprecated getMainApplicationFrame() method, replaced by getCurrentWindow().
Beware though that to be able to use in a FID, you will need to give it a name, and then pass this name as second parameter of the busy() method of the plugin (this parameter didn’t exist before).
This is because to get a hold of the dialog I have to loop on the Window array returned by the Window.getOwnedWindow() method, and check the name of the dialog, which means that one need to give the name of the dialog to be able to work with it.
The plugin is available from the code.google.com site, and the code has been commited to SVN.
Which leads to this problem in the API: when using IClientPluginAccess.getCurrentWindow(), if I believe what the API says, I should to get a handle of the JDialog in case of a FID.
Indeed, the comment for this method says:
public-api:
Window getCurrentWindow()Get the current showing window (Dialog or Frame) Use this one as a parent if you want to display a dialog or other frame
When in fact, even in a dialog, this method returns the main window.
So either the comment is misleading, or this is a bug.
Can a Servoy engineer explain this, please?
Thanks,
ptalbot:
I have added support for dialogs (FID) for the busy plugin, and got rid of the usage of the deprecated getMainApplicationFrame() method, replaced by getCurrentWindow().
Excellent. Thanks, Patrick.
Patrick,
The getCurrentWindow() issue has already been fixed in next major release of Servoy.
Rob
rgansevles:
The getCurrentWindow() issue has already been fixed in next major release of Servoy.
Thanks Rob! Does that mean Tano?
I have heard it call that before, so yes