Web 2.0 date picker on WebDialog problem

Targets Web
1

The picker appears below the dialog in relation to its dialog position. If you place one near the bottom of a dialog, it will not even show up.

2

Same problem if you place a container control inside a dialog with the date picker… I keep feeling dead in the water on web 2.0. Any work arounds?

3

The same thing happens to me.

Fortunately I have not migrated to version 3.

1 Like
4

If you manually resize the browser window, does the calendar moves to the correct position?

5

BUG 66546 - Webdatepickers misplace calendar if used in a webdialog

http://jason66546.xojocloud.net

I am told by Xojo that it must not be too big a problem because it is does not have many votes. PLEASE take a moment to vote for it.

6

The usual … answer. many people dont even bother to complain or vote any more. Lets keep the mediocre releases, if they dont complain it is good enought for them… if they keep paying for crappy releases lets keep the crappy releases. FC 61792 is more than a year old and something as basic as the UI that affects the end user has no priority?

As for hacks/workarouds… well, since the framework written by xojo changes the top of the element each time is whown and the lack of events to let you know that the calendar was open is not easy to write a hack in xojo.

So, if you relly have to use web 2.0, the alternative is to fix the buggy “framework” yourself, in windows go to C:\Program Files\Xojo\Xojo 2021r3\Xojo Resources\WebFrameworks\XojoWeb\Libraries\Xojo, open the Xojo.js file and search for the “datepicker().on(“show”,function(e){” and fix the positioning.

You can even get rid of the whole function, maybe just change the show event for hide or whatever and let the element position itself instead of using the xojo “framework” code.

Im still using web 1.0. quality of 2.0 is not worth the money.

3 Likes
7

man they still holding on to that argument…

8

I guess the function works for webpages but not webdialogs. I’m not sure what it tries to fix. Maybe someone with JavaScript experience that can read the Xojo.js code

        if ($(l).datepicker(r), this.mEnabled && ($(l).datepicker("setStartDate", r.startDate), $(l).datepicker("setEndDate", r.endDate), $(l).datepicker().on("show", function(e) {
                let t = document.querySelector("div.datepicker");
                if (t && i) {
                    let e = o.absoluteLeft(),
                        n = o.absoluteTop() + i.offsetHeight;
                    Math.abs(t.offsetLeft - e) > i.offsetHeight && (t.style.left = e + "px"), Math.abs(t.offsetTop - n) > i.offsetHeight && (-1 == Math.sign(t.offsetTop - n) ? t.style.top = n - i.offsetHeight - t.offsetHeight + "px" : t.style.top = n + "px")
                }
            })), t) {
            let e = this;
            $(l).on("change", function(t) {
                let i = document.getElementById(e.controlID("_input"));
                i && e.valueChangeHandler(i.value)
            })
        }

on a simple test, changing “shown” to “nshown” seems to work correctly. No time to test more right now.

Edit: case 66546 at Rank 27th now.

1 Like
9

Rank 18th now. It is a shame that a BUG so basic that affects the end user had to be voted to be fixed :roll_eyes:

3 Likes
10

Before changing the code:
datedialogorig.2022-01-17 11_00_45

After changing the code:
datedialogchange.2022-01-17 11_01_20

2 Likes
11

Fantastic!