Re: Bidirectional binding enhancement
Hi, We had something very similar in Eclipse-Databinding so I think something like that makes a lot of sense but I wonder how you want to implement this FOCUS, ACTION. Another thing we had was a delayed-Observable where the sync only happened if there hasn't been a change with a user specified timeout which fairly nice to implement undo/redo like stuff eg in TextAreas. As you don't have access to Node in javafx.base I'm not sure how you want to implement the trigger stuff. Just in case in Eclipse-Databinding world we had stuff like this in a module (in this case OSGi-Bundle) who has access to both the core-API and the ui-API. Tom Am 10.11.21 um 06:45 schrieb Michael Strauß: JavaFX developers routinely use programming patterns like MVC, MVP, or MVVM to separate views from their associated business logic. Bindings can be used to connect the values of UI controls (like Label or TextField) to properties on a business logic class. A typical (simplified) scenario may look like this: var valueField = new TextField(); valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); The business logic class may perform data validation or other actions on the value that was entered in the TextField. However, in many cases, it is neither necessary nor desirable for the binding to update the business-layer property on every single change (i.e. every single character that was typed by a user). For example, if a business rule verifies that the data entered by a user is formatted in a specific way, it's usually not a great experience to yield a validation error before the user has finished typing. Instead, it's often better to wait until the user has significantly interacted with a UI control before running business logic. For this reason, I propose to add a new type of binding to the javafx.beans.binding.Bindings class: void bindBidirectional(Property target, Property source, UpdateSourceTrigger trigger) UpdateSourceTrigger is an enumeration that allows developers to specify the condition on which changes of the target property will update the source property. Its values are: DEFAULT: Updates the source property on every change (this is the default behavior of bidirectional bindings). FOCUS: Updates the source property when the UI control loses input focus. ACTION: Updates the source property when the UI control loses input focus or when it receives an ActionEvent (in the case of TextField, this corresponds to the ENTER key). Note that this setting only applies to changes of the target property. When the source property is changed instead, the target property is always immediately updated. Any feedback on this proposal is appreciated. -- Tom Schindl - CTO BestSolution.at EDV Systemhaus GmbH Salurner Straße 15, A-6020 Innsbruck Phone: ++43 (0)512 935834 http://www.BestSolution.at - http://efxclipse.org
Bidirectional binding enhancement
JavaFX developers routinely use programming patterns like MVC, MVP, or MVVM to separate views from their associated business logic. Bindings can be used to connect the values of UI controls (like Label or TextField) to properties on a business logic class. A typical (simplified) scenario may look like this: var valueField = new TextField(); valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); The business logic class may perform data validation or other actions on the value that was entered in the TextField. However, in many cases, it is neither necessary nor desirable for the binding to update the business-layer property on every single change (i.e. every single character that was typed by a user). For example, if a business rule verifies that the data entered by a user is formatted in a specific way, it's usually not a great experience to yield a validation error before the user has finished typing. Instead, it's often better to wait until the user has significantly interacted with a UI control before running business logic. For this reason, I propose to add a new type of binding to the javafx.beans.binding.Bindings class: void bindBidirectional(Property target, Property source, UpdateSourceTrigger trigger) UpdateSourceTrigger is an enumeration that allows developers to specify the condition on which changes of the target property will update the source property. Its values are: DEFAULT: Updates the source property on every change (this is the default behavior of bidirectional bindings). FOCUS: Updates the source property when the UI control loses input focus. ACTION: Updates the source property when the UI control loses input focus or when it receives an ActionEvent (in the case of TextField, this corresponds to the ENTER key). Note that this setting only applies to changes of the target property. When the source property is changed instead, the target property is always immediately updated. Any feedback on this proposal is appreciated.
Re: RFR: 8274929: Crash while reading specific clipboard content
On Wed, 10 Nov 2021 00:53:24 GMT, Michael Strauß wrote: > Then shouldn't we also not trust the data if bufferSize is larger than it > needs to be? Yes, that's a good point. In order to avoid integer overflow, I'll probably leave the two existing tests, and add a third (or else do the test using a `jlong`). Something like this should work: jsize bufferSize = me.size() - sizeof(UINT); if ((pdata->cItems > 0) && (bufferSize / pdata->cItems >= itemSize) && (bufferSize == pdata->cItems * itemSize)) I'll update this tomorrow. - PR: https://git.openjdk.java.net/jfx/pull/662
Re: RFR: 8274929: Crash while reading specific clipboard content
On Wed, 10 Nov 2021 00:31:05 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line >> 1307: >> >>> 1305: jsize bufferSize = me.size() - sizeof(UINT); >>> 1306: if ((pdata->cItems > 0) && >>> 1307: (bufferSize / pdata->cItems >= itemSize)) >> >> Instead of discarding all the data, have you considered reading >> `min(pdata->cItems, bufferSize / itemSize)` items? > > I thought about it, but since failing this test means that `cItems` is > invalid, there is no reason to believe that the data that follows it is any > less invalid. Then shouldn't we also not trust the data if `bufferSize` is larger than it needs to be? The documentation of `FILEGROUPDESCRIPTORA/W` says that `cItems` should correspond exactly to the numer of items in the array that follows. - PR: https://git.openjdk.java.net/jfx/pull/662
Re: RFR: 8274929: Crash while reading specific clipboard content
On Tue, 9 Nov 2021 23:46:18 GMT, Michael Strauß wrote: >> This bug is caused by not sanity checking the data returned by a call to the >> Windows Clipboard `IDataObject::GetData` method. When requesting a file >> descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or >> `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word >> of the returned data buffer is supposed to be the number of items that >> follow. Applications can put data on the clipboard in such a way that it >> will respond to a request to return the list of files from the clipboard >> with data that isn't formatted correctly, so we can't assume that the first >> word is a valid count. >> >> The fix is to check the returned buffer size against the item count. I added >> a regression test that fails before and passes after the fix. > > modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line > 1307: > >> 1305: jsize bufferSize = me.size() - sizeof(UINT); >> 1306: if ((pdata->cItems > 0) && >> 1307: (bufferSize / pdata->cItems >= itemSize)) > > Instead of discarding all the data, have you considered reading > `min(pdata->cItems, bufferSize / itemSize)` items? I thought about it, but since failing this test means that `cItems` is invalid, there is no reason to believe that the data that follows it is any less invalid. - PR: https://git.openjdk.java.net/jfx/pull/662
Re: RFR: 8274929: Crash while reading specific clipboard content
On Tue, 9 Nov 2021 16:57:58 GMT, Kevin Rushforth wrote: > This bug is caused by not sanity checking the data returned by a call to the > Windows Clipboard `IDataObject::GetData` method. When requesting a file > descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or > `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word > of the returned data buffer is supposed to be the number of items that > follow. Applications can put data on the clipboard in such a way that it will > respond to a request to return the list of files from the clipboard with data > that isn't formatted correctly, so we can't assume that the first word is a > valid count. > > The fix is to check the returned buffer size against the item count. I added > a regression test that fails before and passes after the fix. modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 1307: > 1305: jsize bufferSize = me.size() - sizeof(UINT); > 1306: if ((pdata->cItems > 0) && > 1307: (bufferSize / pdata->cItems >= itemSize)) Instead of discarding all the data, have you considered reading `min(pdata->cItems, bufferSize / itemSize)` items? - PR: https://git.openjdk.java.net/jfx/pull/662
RFR: 8274929: Crash while reading specific clipboard content
This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. - Commit messages: - 8274929: Crash while reading specific clipboard content Changes: https://git.openjdk.java.net/jfx/pull/662/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274929 Stats: 115 lines in 3 files changed: 111 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/662.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/662/head:pull/662 PR: https://git.openjdk.java.net/jfx/pull/662
Re: RFR: 8227371: Drag&Drop while holding the CMD key does not work on macOS
On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox wrote: > During a drag-and-drop operation on the Mac the Command key will filter out > every drag source operation except `NSDragOperationGeneric` (this behavior is > provided by the OS). JavaFX drag sources only set the Move, Copy, and Link > drag operation bits so the Command key reduces the set of available > operations to nothing. > > This PR changes nothing about how JavaFX behaves when the dnd operation > involves an external application. As a drag source the same set of operations > will be broadcast and as a drag destination the operations will be > interpreted as they have always been. > > For internal dnd within the JavaFX app `NSDragOperationMove` and > `NSDragOperationGeneric` will both be set if the drag source specifies > `TransferMode.MOVE`. On the other end a drag destination will interpret > `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms. > > As part of this PR it was necessary to verify that `NSDragOperationGeneric` > was not already being used during an internal drag operation. There's a > clause in `mapJavaMaskToNsOperation:` which translates > `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this > includes the Generic bit. I believe this is a red herring, the Java dnd code > converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so > `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the > platform level. Looks good to me. I tested the testcase attached in JBS on macOS BigSur and I can see the move operation is selected if cmd key is pressed after the fix. - Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/651
