PC v MAC webdialog populate

TIG

I have a cross platform web-dialog based tool that has checkboxes.
By default many of these checkboxes start 'unchecked'.
The initialize/active section of the tool sets the 'values' to either a set of 'standard defaults' or the last used set of values, that are remembered as 'attributes' in the SKP.
It currently shows the web-dialog thus
@dlg.show{self.populate()}
where the 'populate' def runs when th html has loaded.
On a PC all is fine - no problems at all.
On a MAC it fails to adjust the checkedboxes options completely.
I've added
@dlg.show{ sleep(2) self.populate() }
etc to pause the MAC, all to no avail. It's as if the MAC is trying to 'populate' the dialog BEFORE its finished loading and so it fails...

Any ideas on this weirdness ?

thomthom

The script is probably triggered before the HTML document is ready.

What I do is add an event to the load event of the document (I use jQuery which hooks into the OnDOMLoad event so it triggers when the HTML is ready - before images and other external resources are.)

That event then triggers a call-back to Ruby where I do my initialisation. That ensures that the webdialog truly is ready.

thomthom

By the way - what does your populate method do? How are you populating the webdialog? You aren't running into the async problem from webdialog->Ruby issue on OSX, are you?

TIG

@thomthom said:

By the way - what does your populate method do? How are you populating the webdialog? You aren't running into the async problem from webdialog->Ruby issue on OSX, are you?

What async problem
For example - my populate def finds the current state of @resolution and says

if @resolution=="true"
      js=("document.getElementById(\"resolution\").setAttribute(\"checked\",true);")
      @dlg.execute_script(js)
      js=("document.getElementById(\"resolution\").setAttribute(\"value\",true);")
      @dlg.execute_script(js)

Then within the html it says if the check-box 'resolution' in clicked...

onclick="if(this.checked)(window.location='skp;resolution@true');else(window.location='skp;resolution@false');">

where def resolution in the ruby does...

def resolution(p)
    @resolution=p
    if @resolution=="true"
      js=("document.getElementById(\"resolution\").setAttribute(\"checked\",true);")
      @dlg.execute_script(js)
      js=("document.getElementById(\"resolution\").setAttribute(\"value\",true);")
      @dlg.execute_script(js)
      js=("document.getElementById(\"width_label\").setAttribute(\"disabled\",false);")
      @dlg.execute_script(js)

etc etc...........
This tries to tie together value and checked...
Fine on the PC, but fails on the MAC...

Didier Bur

Hi TIG,

Maybe a little off topic but for my su2pov script I've decided to code methods that write HTML files for my dialog boxes. I find that more convenient. So I have to maintain a set of options in a hash, read these values before writing the HTML file accordingly, then load the web dialog. I've encountered many problems with checkboxes, radio buttons and the like using the usual design method for web dialogs.
Below is a snippet of code to write a part of the html dialog. Radio buttons for instance need a hidden ID to be able to retrieve their values, same goes for checkboxes I think.
In this example, I have 3 radio buttons "Off", "Normal", "Fine" to select an antialias setting.

@html.puts("<tr>")
			@html.puts("<td style=\"width; 100px;\">Antialias</td>")
			@html.puts("<FORM name=\"radioIaa\">")
			@html.puts("<input type=\"hidden\" id=\"antialias\" value=\""+ ocr_options["Iaa"] +"\">")
			@html.puts("<td>")
			if ocr_options["Iaa"]=="Off"
				@html.puts("<input type=\"radio\" name=\"iaa\" value=\"Off\" onClick=\"document.forms.radioIaa.antialias.value='Off'\" checked>Off")
			else
				@html.puts("<input type=\"radio\" name=\"iaa\" value=\"Off\" onClick=\"document.forms.radioIaa.antialias.value='Off'\">Off")
			end
			if ocr_options["Iaa"]=="Normal"
				@html.puts("<input type=\"radio\" name=\"iaa\" value=\"Normal\" onClick=\"document.forms.radioIaa.antialias.value='Normal'\" checked>Normal")
			else
				@html.puts("<input type=\"radio\" name=\"iaa\" value=\"Normal\" onClick=\"document.forms.radioIaa.antialias.value='Normal'\">Normal")
			end
			if ocr_options["Iaa"]=="Fine"
				@html.puts("<input type=\"radio\" name=\"iaa\" value=\"Fine\" onClick=\"document.forms.radioIaa.antialias.value='Fine'\" checked>Fine")
			else
				@html.puts("<input type=\"radio\" name=\"iaa\" value=\"Fine\" onClick=\"document.forms.radioIaa.antialias.value='Fine'\">Fine")
			end
			@html.puts("</td>")
			@html.puts("</FORM>")
		@html.puts("</tr>")

In the callback function, I retrieve and store the value of the option with:

ocr_options["Iaa"] = d.get_element_value "antialias"

It works fine

thomthom

The async problem: http://forums.sketchucation.com/viewtopic.php?f=180&t=23445

Not sure if that is related to your issue here though.
But I do wonder if you need to be passing the click event of the checkbox to ruby then back to JS again. Isn't it easier to just keep it in JS?

Have you tried to set the checked and disabled attributes with string values? 'checked' and 'disabled' instead of true/false?

As you can see from the W3C specs: http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.4
checked (checked) #IMPLIED -- for radio buttons and check boxes -- disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED -- for text and passwd --
So in HTML code you'd write <input type="checkbox" value="something" checked="checked">

You might have to use strings instead of booleans. Can't remember exactly what the safest cross-browser method was. These says I use jQuery.

TIG

Thanks for the link. Unfortunately I think it's not that relevant...

I originally had the "value" set as 'true'/'false' "strings" rather than true/false "booleans", and although it was fine on the PC it wasn't working on the MAC: so I changed it to use the "booleans" and it's still OK on the PC... but it still fails on the MAC ! The "checked" seems to work as either a 'string' or 'boolean' on the PC but not on the MAC
Also the @dlg.get_element_value(id) always returns a "string" even if it's a "boolean" in the html...

I'll try recoding again with all 'strings', and change the if(this.checked)... [boolean] to if(checked=='true')... I'm sure it'll work on the PC either way BUT MACs are another world........

TIG

OK, so far I find this - for PC and i must assume the same for MAC [?]

The html attributes checked and disabled must be booleans =true/=false
If you use a 'string' value - including ='false' - it always returns true [boolean] - I assume because a 'string' is 'something' and a false boolean is 'nothing'?
The value attribute must be a 'string': I pair the checked and value with the test
onclick="if(this.checked)(window.location='skp:resolution@true');else(window.location='skp:resolution@false');"
Which says if this [checkbox] is checked [true as boolean] then do a callback passing 'true' skp:resolution@true [which is set in the rb file] and this sets the values of various related dialog items - e.g. setting that item's 'value' to match [ checked >>> value='true'] making other checkboxes checked/unchecked and enabled/disabled to suit [the 'else' test does the same callback passing 'false' etc].
This all works fine on my PC...

One thing I do notice is if I add


@dlg.show{
  sleep(2)
  self.populate()
}

It will initially show the dialog with all of the checkboxes ticked - although in the html it has checked=false !!! and then after 2 seconds the populate() kicks in and updates them all to suit... On the MAC version it seems as if it does the initial step and then fails on the populate() ??? Very puzzling

So it all works fine on a PC. Initially I did have a callback inside the html to run populate() as an onLoad= js function within the html's <body > tag but this caused a js parse child/parent error message for a few PC users (Win7+Chrome), which did nothing and it ran OK on a Yes reply, so I decided to run the populate() in the block of the ruby @dlg.show{} instead - it now works without errors for ALL PC users...

However, for the MAC I have made many permutations of the html attributes and at what point populate() is run and I suspect that if I now get one of my MAC testers [e.g. long-suffering Burkhard] to try out this current version it'll still hiccup at the self.populate() step and so fail to change the checkboxes' values to the preset 'defaults' [or to the SKP's attributes as previously saved as attributes otherwise]...

I can't find anything otherwise that tells us the dialog is fully loaded - if there were we could wait for it and then run populate() - but isn't that what the
[ruby:2tujxofo]@dlg.show{once_its_loaded_we_can_do_more_commands_in_this_block}[/ruby:2tujxofo]
does ???

Dan Rathbun

@tig said:

I can't find anything otherwise that tells us the dialog is fully loaded - if there were we could wait for it and then run populate() ...

Js Example (from MSDN)
See: [onreadystatechange Event](http://msdn.microsoft.com/en-us/library/ms536957(v)

// JavaScript
document.onreadystatechange=fnStartInit;

function fnStartInit()
{
   if (document.readyState=="complete")
   {
      // Finish initialization.
   }
}

I'd think the handler function declaration, and the statement to register it would need to go in a <SCRIPT> element in the <HEAD> section.

TIG

Dan thanks,

I had this in the header

<script type="text/javascript">
  function nowpopulate() {
    window.location='skp;populate@';
  }
</script>

which runs the ruby populate code
and this in the 'body tag'

<body onLoad="nowpopulate()">

which runs nowpopulate once all of the html has loaded
This works fine on a PC but fails on a MAC.

The way I currently have it set up is - with no js in the html and 'onLoad=' in the body, but instead within the ruby @dlg.show{self.populate()} which supposedly runs populate after the dialog is loaded - this works fine on a PC but fails on a MAC.

I have also tried your suggested method [using fnStartInit] in the html and in the ruby @dlg.show{}... and that seems to work exactly the same on my PC as the other methods - i.e. it's all fine - but it's not yet been tested on the MAC - I'll get it tested by someone and report back...

Didier Bur

Hi TIG,
Did you test with a 'yield' statement ?

TIG

@didier bur said:

Hi TIG,
Did you test with a 'yield' statement ?

Please explain 'yield' a little more...

thomthom

I think element.checked is a true/false boolean, but element.setAttribute('checked', x) - x should be either 'checked' or ''.

TIG

Thanks for all of the input...
Setting checked to be almost ANYTHING returns true [checked] on a MAC - even ='' is true! I'm about to try checked=null to see if that helps to 'uncheck' items on a MAC.
On a PC you can have checked=true [>>>true], checked=false[>>>false] or even checked='true' [>>>true], checked='false'[>>>false]... but on a MAC they are all *true*.
Also learnt that checked="checked" is the only way to set checked to be true in XHTML !!!
This area of coding is a mess...

Dan Rathbun

Is your checkbox control wrapped withIN a <FORM> element?

Some of the input control attributes may rely on being inside a FORM.
Safari could be nitpicky about this.

It seems to me I have a vague memory of having similar problems.
I think I just kept track of the checked state myself (with a Js var,) using the onClick event.

The only other thing I would suggest is playing with the HTML spec compliance settings in the <!DOCTYPE> tag and see if that makes a difference.

Dan Rathbun

[floatr:j2u13kn5]

[/floatr:j2u13kn5]TIG.. I did some checking over at the Apple Discussions

Did a search on "input type=checkbox"
and got a couple of hits with sample code.

It looks like these guys are using "0" and "1"
as the checked property value:

%(#804000)[<TD><input type="checkbox" name="AutoLogin"]%(#BF4000)[**value="1"**]%(#804000)[>Automatic Login</TD>]

URL:Topic : Safari ... cannot redirect to locations starting with "(null):" -- What?

%(#804000)[<label for="cb_cookieuser_navbar"> <input type="checkbox" name="cookieuser"]%(#BF4000)[**value="1"**]%(#804000)[tabindex="103" id="cb_cookieuser_navbar" accesskey="c" />Remember Me?</label>]

URL: Topic : Safari Browser does not play well with vbulletin forums (save login?)!

TIG

Dan, thanks. I have checked="checked" [i.e. checked] and checked=null [i.e. false] working fine on a PC and I'm waiting for feedback from some MAC testers...
The value= attribute is separate from the checkbox= issue - So I can get SUp to read the 'value' from the item I have to set its value='true' or 'false' according to the item's checked state - this is fine... BUT as I want to change the checked status of a checkbox with js (perhaps because some other checkbox changes these should not be checked either) then I change the value and checked together - fine on PC but fails on a MAC - though the jury's out on checked=null till the feedback arrives...
If the null option fails on the MAC I'll look at testing the value='0' / '1' alternatives

I really can't seen where this is falling over........

thomthom

have you considerd using a framework that will take care of these crossplatform issues for you? They are great time savers. Lets you focus on the making.

TIG

I am currently getting favorable results for the MAC testers using checked="checked" and checked=null !!!
The PC version already worked... so I'll report back when the jury's verdict is finalized.

TIG

I think I have the solution

document.getElementById("myCheckBox").setAttribute("checked", "checked");
document.getElementById("myCheckBox").setAttribute("checked", null);
document.getElementById("myCheckBox").removeAttribute("checked");

The first line 'checks' a checkbox in js... BUT... to 'uncheck' it the second AND third lines are needed
Some browsers/OSs want you to set its value to something 'false' [like null or false or ''], BUT some other browsers/OSs will take any setting at all to be 'true' and will therefore still 'check' it irregardless... so the only way to then 'uncheck' it is to remove its 'checked' attribute completely as in the third line!
Combining the last two lines should 'uncheck' a checkbox in most browsers/OSs ?
On a PC the second alone works but the third alone fails [and is ignored].
On a MAC the second alone fails but the third alone works.
Combining them should work 'cross-platform'