FWD » Core Development » User Interface

Dragging a node will drop a different node in the target node.

Any idea of how long this has been broken?

Greg Shah wrote:

Any idea of how long this has been broken?

No idea. Do you want me to figure out?

No. Knowing that isn't that important unless the bug turns out to be tricky.

Greg Shah wrote:

Any idea of how long this has been broken?

It was working at least when the #5177 was closed about a year ago.

Hynek, what do you mean by "broken"? Which code did you use for testing?

I just tested my treeview example, which was designed after the customer application, and it still works as expected. The application allows the user to reorder nodes in a treeview by dragging them.

Roger, have you seen any regression either?

Vladimir Tsichevski wrote:

Roger, have you seen any regression either?

Ever since the 14484 merge to trunk, I have not been able to run the customer application (#7145 and #7146). #7135 is required to perform the conversion, but then those 2 issues prohibit the runtime from working.

I am working on building with the latest re-based 7135a to determine if there is any change in that.

Using branch 7135a rebased with 14491, the customer application's "Organize Favorites" functions just fine. In their app, I had added 8 favorites, 3 handled labels, 2 handled details, and 3 handled "other stuff". When I organized them into 3 folders, one for Labels, one for Other, and the other for Details by drag-drop, they were in the correct folders.

I will double check the uast test case, perhaps it's just buggy.

Hynek Cihlar wrote:

Vladimir, please see the attached screen cast. Tested on latest trunk.

Could you provide the FWD test example, please. The testcases/uast/oledragdrop/treeview.p is not adapted for FWD and depends on user32.dll.

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir, please see the attached screen cast. Tested on latest trunk.

Could you provide the FWD test example, please. The testcases/uast/oledragdrop/treeview.p is not adapted for FWD and depends on user32.dll.

So is this an issue of GetCursorPos or ScreenToClient? If so we can close this and open new one to address the user32 calls.

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

So is this an issue of GetCursorPos or ScreenToClient? If so we can close this and open new one to address the user32 calls.

Do you mean the calls to user32.dll must be converted transparently to NativeAPIEmulation, and the problem is they are not?

I just wanted to point out that I used branch 7135a, which had a modification to the conversion of GET-MOUSE-POSITION (see #7135-16) that isn't part of trunk yet. Since it created a conversion error of this code:

PROCEDURE getMousePoint :
  DEFINE INPUT  PARAMETER pcObject AS HANDLE NO-UNDO.

  DEFINE VARIABLE iMouseLoc AS INTEGER NO-UNDO EXTENT 2.

    ASSIGN 
      iMouseLoc = pcObject:FRAME:GET-MOUSE-POSITION().
END PROCEDURE.

I doubt it has any relation to this issue, but wanted to make sure you knew there was a branch with a fix in that area.