[SOLVED] Address Lookup

Hi Luca

Thanks for your explanation did you get round to doing the below?

Also, I will send you an updated sample with the crafty clicks plugin as a component instead of a control, this was you can attach it to any existing TextBox and can even have multiple on the same page.

Many Thanks

Ewan

Hi Ewan,

It works with VWG and on their site, as well as simple samples, only when z-index is not used. Wisej has the z-index set on all the elements that correspond to widgets. As soon as a div in the hierarchy has a z-index value (any value) they cannot have a div partially behind and partially in front. See the jsfiddle link I added in the previous answer.

You can also try the demo page on their site, use F12 in chrome and add a z-index value on the parent div and it stops working.

When you look at the dom, they create the overlay div outside of the hierarchy of the target div and try to display the target div in front but the container of the target behind. It looks to me that it’s a bug in the browsers – a div cannot be partially in front of another div while at the same time be behind a child of the div that is behind. It’s not best practices, it’s simply wrong and it works in some cases probably because of a bug or some old compatibility stuff.

Best,

Luca

Hi Luca

Thanks sorry for the delay in replying just got back from holiday.

It is strange that it works in VWG using a popup form with an html box.

I looked into this again and managed to pinpoint the bug in crafty clicks that prevents gfxMode 2 from working correctly. Using an htmlbox won’t work in Wisej. The problem is that they create the overlay div in the wrong position in the dom and relay on the absence of the z-index style on parents to render the wrong layering. It should be impossible in a browser to have a div behind another div but showing partially on top.

So this looks like an issue with the way Crafty Clicks have written their code which from your comments does not appear to follow best practice, is this the case in your opinion?

Many Thanks

Ewan

Hi Ewan,

I looked into this again and managed to pinpoint the bug in crafty clicks that prevents gfxMode 2 from working correctly. Using an htmlbox won’t work in Wisej. The problem is that they create the overlay div in the wrong position in the dom and relay on the absence of the z-index style on parents to render the wrong layering. It should be impossible in a browser to have a div behind another div but showing partially on top.

In fact as soon as any div in the hierarchy above the target element has a z-index value (any value) their overlay doesn’t work. See the jfiddle sample:

https://jsfiddle.net/wisej/frpaymxj/1/

The same bug is reproducible on their web site, it’s enough to open dev tool and add a z-index anywhere above the input. Wisej adds the z-index to all the elements it creates to manage the… z-index without having to move elements around. Which is the purpose of the z-index.

Unless there is a fix, it cannot work in gfxMode 2.

Also, I will send you an updated sample with the crafty clicks plugin as a component instead of a control, this was you can attach it to any existing TextBox and can even have multiple on the same page.

Best,
Luca

Hi Ewan,

Getting to it. Sorry for the long wait.

Best,

Luca

Hi Luca

Did you ever find time to post a version using an HTML box?

Thanks for all you do

Ewan

The elements don’t have IDs, you can get the element itself since in Wisej they don’t change. If you pass the control ID to the URL:

string url += "?id1=" + ((IWisejComponent)this.textBox1).Id;

On the client side you can read it like this:

var args = qx.util.Uri.parseUri(location.href);
var id1 = args["id1"];

Then to find the textBox1 widget on the client side:

var widget = Wisej.Core.getComponent(id1);

To get the dom element:

var el = widget.getContentElement().getDomElement();

However, in the case of wisej.web.TextBox (and ComboBox and DateTimePicker), the element is not the <input> element since the <input> is wrapped inside in order to add buttons around it. The actual input is called “textfield”:

var field = widget.getChildControl("textfield");
var inputEl = field.getContentElement().getDomElement();

The dom element can be null if you try to get it too early before the widget is rendered.

In any case, I will upload different versions of this integration using the html box and will also try to fix the problem they have wrapping a div in a div.

HTH

Best,

Luca

Hi Luca

If I use an HTML panel in a popup control to host the Crafty Clicks Java Script how do I pass the control IDs of the address fields into the HTML panel?

How do I access the textbox values via the control ID in JavaScript in the HTML Panel so I can perform address verification?

Many Thanks for your help

Ewan

Hi Luca

I raised a support call with Crafty Clicks on this issue and they looked at what was going on via Finch.

Their developers view is that there is a conflict between the WiseJ Element Z order and the Crafty Clicks Element Z Order which is why the text box does not show as its behind with gfxmode: 2. Don’t know whether you have any ideas on this one? (A hack is to edit the CSS so the Background is transparent)

Knowing how to pass the address text boxes as a set of parameters into the JavaScript so an existing address can be verified would also be a great help

Thanks for your help

Ewan

Hi Luca

If I pick gfxMode: 2 which shows the county above the data entry box, it does not work correctly. I am after a look similar to the attached.

New trail code =

5aeff-968e0-724b8-01df7

See also comments above.

Many Thanks for your help

Ewan

Hi Ewan,

sorry for the delay.

Find a revised version of your sample here:

http://wisej.s3.amazonaws.com/support/attachments/Wisej.ClickToAddress.zip

Try using it with parameters #Page1, #Page2 to your URL.

Please make sure to upgrade to the latest wisej build first (1.3.14).

Best regards
Frank

Hi Ewan,

we are working on a Wisej version of your sample and will send you the code next week.

Best regards
Frank