DICE PACKS BUNDLE
  1. #1

    windowlist getPosition() totally off

    I am trying to identify the current cursor position of a user on a windowlist.
    So I am using this code:
    Code:
    ...
    DebugManager.printDebugMessage2(sScriptName, sFuncName, "window: ", window);
    DebugManager.printDebugMessage2(sScriptName, sFuncName, "x: ", x);
    DebugManager.printDebugMessage2(sScriptName, sFuncName, "y: ", y);
    local winlistEntry = window.getWindowAt(x, y);
    if winlistEntry and winlistEntry.shortcut then
                            local xLinkMin, yLinkMin = winlistEntry.getPosition();
                            DebugManager.printDebugMessage2(sScriptName, sFuncName, "xLinkMin: ", xLinkMin);
                            DebugManager.printDebugMessage2(sScriptName, sFuncName, "yLinkMin: ", yLinkMin);
                            local xTmp, yTmp = winlistEntry.shortcut.getPosition();
                            DebugManager.printDebugMessage2(sScriptName, sFuncName, "xTmp: ", xTmp);
                            DebugManager.printDebugMessage2(sScriptName, sFuncName, "yTmp: ", yTmp);
                            DebugManager.printDebugMessage2(sScriptName, sFuncName, "winlistEntry: ", winlistEntry);
                            DebugManager.printDebugMessage2(sScriptName, sFuncName, "winlistEntry.shortcut: ", winlistEntry.shortcut);
    ...
    end
    and I am getting this output:
    Code:
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, window: ' | windowlist = { windows = #29, name = s'inventorylist1', x,y,w,h = 25,47,448,260 }
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, x: ' | #435
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, y: ' | #557
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, xLinkMin: ' | #929
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, yLinkMin: ' | #541
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, xTmp: ' | #426
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, yTmp: ' | #3
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, winlistEntry: ' | windowinstance = { class = charsheet_inventoryitem_all, node = charsheet.id-00006.inventorylist.id-00027, x,y,w,h = 0,546,448,21 }
    [4/1/2024 8:22:42 PM] s'gm                |  scripts/manager_droptype_dsa.lua, processListDrop, winlistEntry.shortcut: ' | windowreferencecontrol = { name = s'shortcut', x,y,w,h = 426,3,20,16 }
    The shortcut is a match and seems to be correct - but the windowlist x-axis it totally off: #929 vs 0 and the y-axis is #541 vs 546.
    Why do the x and y position of windowinstance output differ so much from the output of the function call? Obviously, winlistEntry knows its correct position?
    Am I missing something?

  2. #2
    According to the documentation windowlist inherits from windowcontrol and windowinstance, which both implement getPosition(). Unfortunately, windowinstance.getPosition() delivers the position relative to the screen. However, I would need the implementation of windowcontrol.getPosition() which delivers the position relative to the parent control. Is there any way to enforce the usage of getPosition of windowcontrol? Or is there any other way to get the relative position of my windowlist window so that I can compare with my x and y position in the onDrop handler that I try to implement?

  3. #3
    The documentation states that windowlist inherits from "windowcontrol, databasecontrol", not "windowinstance".
    As noted in the documentation, windowinstance.getPosition() always returns tabletop coordinates; while windowcontrol.getPosition() always returns internal window coordinates.

    If you capture the event in a windowlist.onDrop event, you can call windowlist.getWindowAt(...) API to determine the child window dropped on.
    Otherwise, you can track onHover events over specific controls.

    Regards,
    JPG

  4. #4
    Well, this is what I am doing: I am in the windowlist.onDrop event. and as you can see I am using
    local winlistEntry = window.getWindowAt(x, y);
    and afterwards
    local xLinkMin, yLinkMin = winlistEntry.getPosition();
    which gives me
    winlistEntry: ' | windowinstance = { class = charsheet_inventoryitem_all, node = charsheet.id-00006.inventorylist.id-00027, x,y,w,h = 0,546,448,21 }
    but this Position: 929, 541
    so somehow not the windowcontrol but windowinstance position.
    My problem is that I would like to know the position relative to the parent window in order to compare with the x,y coordinates of the onDrop event.
    I am not sure I am able to process the onDrop while simultaneously evaluating the onHover event on the windowreferencefield
    Last edited by JMessmer; April 2nd, 2024 at 06:19.

  5. #5
    I guess my question is what are you trying to do, not how you are trying to do it? What is the purpose of knowing the exact relative location? The API isn't built that way, but I can't suggest an alternative without knowing what you are trying to do. As I was suggesting above, you can capture the onDrop event with controls on the child windows themselves instead, and bypass this whole issue.

    If for some reason, you really want to do it this way, it will be fairly fragile code, since any change to the child window will invalidate your calculations. However, you could potentially do it by calculating the total offset of child window position - (list parent window position + list control position).

    Regards,
    JPG

  6. #6
    Thanks JPG, I really appreciate you trying to help.
    https://i.postimg.cc/tCW01rKJ/inventory-Concept.png
    I guess a picture helps to understand it best. I am in the inventory and figured that intuitively a user wants to update records when dragging an item onto the shortcut section in the windowlist.
    However, when dragging an onto the central list area I think the user wants to add the item to inventory. So I am trying to capture the drop area using the x and y coordinates that come as parameters of the onDrop Event on the windowlist.

  7. #7
    For most rulesets on FG, item records are fully copied entirely into character sheet inventory list space; so the link will only be a self-reference. You wouldn't want to "override" or "update" existing records (other than counts which are handled already by the standard ItemManager transfer code).

    I'm not sure what you mean by "update records" by dragging an item onto the shortcut section. Also, I'm not sure that's what you want to do, since you wouldn't want items accidently being overwritten if the user drops on the shortcut but didn't mean to. Even if that's what you want to do, just capture the onDrop event in the shortcut. Otherwise, let it fall through to the list and be handled as an item add.

    Regards,
    JPG

  8. #8
    The implementation of the dark eye ruleset differs in many aspects a lot compared to other rulesets. The rules of the 4.1st edition are extremely complex.
    Anyway, I want to update the existing records because they have been imported via the "Heldentool". An average person playing the dark eye is not able to generate a character manually. You need a specialized tool for this. And after this import you have a list of "hollow" items bare any functionality in your list (clearly distinguishable by the empty shortcut link). All the missing data like armor values for different body zones, weapon statistics, potion's poisonous or healing levels, magical artefact's skill check requirements for identification - let alone it's usage... all this stuff is in information on the "item" class.
    And actually the item is not only getting updated but instantiated once any drop on the list happens. All the unique information of the item "class" (OOP point of view, not FGU) is being transformed into a specialized windowclasses of armor, weapon, potion, artefact, herb, ... but with its essential information on the inventory item.
    And no, I don't want users to accidentally overwrite any information - this is why I defined the insert zone. Drops in this area check if the items already exist in the list. If yes I increase the count, if not they are being added.
    I will check the onDrop event in the shortcut and add it to my custom dropmanager if I am able to get a large enough zone around the shortcut.

  9. #9
    You can literally just add an override script for the existing item records:

    Code:
    <windowclass name="char_invitem" merge="join">
    	<sheetdata>
    		<linkcontrol_record name="shortcut">
    			<script>
    				function onDrop(x, y, draginfo)
    					if draginfo.isType("shortcut") then
    						local sClass = draginfo.getShortcutData();
    						if LibraryData.getRecordTypeFromDisplayClass(sClass) == "item" then
    						    ...
    							return true;
    						end
    					end
    				end
    			</script>
    		</linkcontrol_record>
    	</sheetdata>
    </windowclass>
    Regards,
    JPG

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
FG Spreadshirt Swag

Log in

Log in