Javascript Behavior

Applications Forms
#1

RESOLVED

I have a form which contains a checkbox. I want to reset it if another field is empty. So I created an ajax event onClick for the checkbox. In that event I have a call to sc_ajax_javascript(“reset_site_disclaimer”);.

In the Javascript Methods I have defined reset_site_disclaimer. Now I know the reset_site_disclaimer is being triggered because I put in an javascript alert which it shows. But the code document.getElementById(“site_disclaimer”).checked = false; is not working. It does not reset the checkbox. What am I missing?

#2

RESOLVED:
What the hell kind of coding crap is this? After spending an hour searching scriptcase I finally found code that works:
$(".sc-ui-checkbox-site_disclaimer")[0].checked = false;

Why the hell can’t I just reference the field name? Why the hell do I need the garbage in front of the field name? Better yet, why the hell isn’t this documented somewhere?

I cannot believe the amount of time I’ve WASTED ON FIGURING OUT SIMPLE CODE. This isn’t the first post I’ve made and eventually come across a solution. We are paying a lot of money for SC and most of it is doing research on getting things to work that seem to be outside their standard configuration. This is become a big issue and frankly NOT FUNNY! Get your act together SC.:mad::mad::mad::mad:

#3

  1. What you call garbage, the rest of the world call javascript\jquery. I think they are the most documented languages\libraries in the world, so it’s well documented in the wild (i.e. google it). Like standard PHP commands, these should not added to the SC docs.

  2. If you ask politely, maybe someone will explain to you how to use selectors in javascript\jquery and why they don’t match the field name you see in the SC IDE.

  3. I don’t know if what you tried to do, could be done by SC, but If you want to do anything SC can’t do with its GUI and\or macros , you need to learn some PHP and\or Javascript (jquery optional). Again, gazillions of information on the internet. Especially on easy stuff like you did in one hour, only because of your lack of knowledge.

#4

robydago, you don’t get it! I’m not calling JS or Jquery crap. I’m calling the internal field names crap. Reread my post. I spent hours trying to get my checkbox to turn off using site_disclaimer which IS THE ACTUAL FIELD NAME. Look at what I had to code to get it to work.

I’m not the only one with issues on how SC has implemented things. This has been an ongoing discussion for weeks.

By the way I’ve coded JS before and never had to use a fictional name like I had too.

I should be able to use document.getElementById(“site_disclaimer”).checked = false;

#5

It takes 0.2 seconds to use a browser inspector to see the javascript element IDs\Names on the SC generated web pages (i.e. running apps).

#6

If you know what you are looking for. Here is another person with the same issue when I eventually found his solution. Dude, don’t lecture me. I know what I’m talking about. I shouldn’t have to use a class when the field name is also in the web page.

http://www.scriptcase.net/forum/foru…ith-javascript

#7

Take it easy. Also, in some browsers using $(".sc-ui-checkbox-site_disclaimer")[0].checked = false; fails, better way is:

$('.sc-ui-checkbox-site_disclaimer').prop('checked',false);
#8

Thanks for the update (much appreciated) but my argument still stands.

#9

“If you know what you are looking for.”

I agree and I’d also add “If you know how to look for it”.
But my point is just that we are talking about standard languages ools, so it’s not for SC to document it.

Actually they should probably not document it, because we (I too do it a lot) are hacking the generated code\page and not using their standard APIs (i.e. SC macros).

Keep in mind that they could change the generated code\page without any warning, even with a very minor SC update and then all your “hacking” code would break.
That’s why I try to put all this kind of code in centralized libraries, so that if needed I can (try to) “fix” it easily.

#10

If they require a certain coding syntax, then yes they need to document it. They also need to fix this forum because I just tried to do a search on

sc-ui-checkbox- and sc-ui.

Guess what, nothing comes up. So how are you supposed to gain knowledge from something that doesn’t work.

#11

So going forward I at least know how to “reference” a field or data type with a prefix of sc-ui with JS or JQuery. This is the part that should be documented by SC. Standard JS or JQuery language is easily accessible via google if you don’t know it, I agree on that point!

#12

To anyone willing to inject JS\Jquery code in a web page to manipulate page elements (e.g. checkboxes), I would reccomend learning to use the browser inspector.

The inspector allows you to check the elements IDs\Names\Classes\Whatever on a web page.
Once you know how to use it, usually it just takes a couple of seconds to get the name of the selector needed to “pinpoint” any element.

And this skill will apply to pages generated by SC or any other tool (or human being).

#13

Below is my original question today which I realize is answered for my purposes by robydago–
[SIZE=14px]To use the Browser Inspect Element view[/SIZE]
Forgot about that while posing my question

So, if I am reading this correctly, jquery methods can be used as specified within a given jquery class in coding ScriptCase 8.1 (latest version) Except That jquery only works in ScriptCase by referencing a specific field or data type with the prefix sc-ui ?