Get_element_value issue (on Mac)

Didier Bur

Hi all,
I'm puzzled with this:
I'm using a WebDialog to get some data from the user, in this case a project name.
Everything works OK on PC, but on Mac "get_element_value returns a void string "".
Anyone encountered this before ? (I didn't find anything related to this issue on this forum, maybe I missed something ?)

in the webdialog method:

@args={}

@project_dialog.add_action_callback("main_dlg_ok") { |d, p|
     @args["projectName"] = d.get_element_value("projectName")
     # other stuff goes here...

     @project_dialog.close			
}

in the HTML file:


<input size="20" form="Project" name="projectName" value="Nom du projet" type="text">	
}

Dan Rathbun

Try using id instead of name, even though both work the same under MSIE, under Webkit things may require using the id attribute. (This could be because of a strict DOCTYPE ?)

<input size="20" form="Project" id="projectName" value="Nom du projet" type="text">

Dan Rathbun

If that does not work.. it is likely an sync issue. The Ruby statements continue to be executed and the one that closes the dialog executes before the value gets returned.

Set up an javascript onChange event for the input, that fires a specific Ruby callback to set the projectName hash member.

HTML

<input size="20" form="Project" id="projectName"
 value="Nom du projet" type="text" onChange="project_name_to_ruby(this.value);">

and JS:

function project_name_to_ruby(proj) {
  window.location = "skp;set_project_name@" + proj;
}

And on the Ruby-side:

@project_dialog.add_action_callback("set_project_name") { |d, p|
  @args["projectName"] = p.strip
}

Didier Bur

Thanks Dan, I'll try that asap and let you know which solution works...

Didier Bur

Hi Dan,
First option (using "id" instead of "name") does'nt work, so clearly this is a sync problem.
Second option (js) works, but what a complex coding for such a simple task... Mac sucks

thomthom

Syncing issue exists only when you send data from JavsScript to Ruby using the window.location = 'skp:......' protocol.

get_element_value is synchronous.

What triggers the "main_dlg_ok" callback? Is the HTML fully ready at that point?

Didier Bur

Hi TT,

@unknownuser said:

What triggers the "main_dlg_ok" callback?

It's a "OK" button:

<input type ="button" value="Valider" onClick="window.location='skp;main_dlg_ok'">

I don't exactly know if the HTML is ready at this point, because it is written "on demand", just after the user clicks on the icon that launches the WebDialog
Regards,

jolran

A longshot.

I noticed some difference in behaviors for button click events if assigning them inside the JS doc.ready functions instead of in the html tag.

I'm using Jquery though..

thomthom

I don't suppose to have a complete reproducible case?

jolran

@unknownuser said:

I don't suppose to have a complete reproducible case?

Who me ?

No, I already sent you code to poke around for fouls

But you can just try putting onclick events in the html tag and see if you notice they missfire occasionally. (Compared to as having a function in the 'doc.ready' that binds the clickevent for the button that is.)

I dont not know why that happend for me. I just cared to mention it as a variable to test since I got the impression Didier was worried the html wasent ready.

jolran

Ahh... Forget my suggestion.
Had a typo in the code that made the clickevent fail in a certain condition.

Thomthom probably knew that something fishy was going on.

So anyone have the solution to this syncing problem for Mac? I'm interested as well..

Didier. Did you make it work ?

Didier Bur

Hi,
I made it work the lazy way: data in the dialog box is saved in a global variable , so when the dialog closes it can be retrieved without js script or anything...

$args={}
@project_dialog.add_action_callback("main_dlg_ok") { |d, p|
			$args["nomProjet"] = d.get_element_value("nomProjet")
                        $args["auteur"] = d.get_element_value("auteur")
...
			@project_dialog.close			
}

Thanks everybody for your help

jolran

That's one way of doing it.

thomthom

Surely an instance variable will work just as well? Avoiding the risk to collision of global variables - especially with a common variable name such as args.