First of all, it is possible?
Second, make something like coordinates in JS. For instance, 300 margin-top, 500 margin-left; make a click with the same effects and values than a normal mouse track in a laptop click.
Last, I don't mean onclick="", onmousedown="" etc. what I'm saying is an action/effect of a user click.
Thanks.
PS: if JS can't make this, another method can be done will be?
.swf objects are mostly a blackbox for javascript. You can "listen" to some stuff in some cases (to an extent, things like when a video is played/stopped etc..but this is not 100% for all browsers/versions, and also depends on how the .swf object is invoked). But "listening" general "actions" within a .swf is not possible with javascript. Depending on what you want to do, you can effectively get the same thing..sometimes...like for instance, detecting a position inside a .swf object someone clicked...if you add an invisible html layer over the object, you can look for some things like clicks and even positions (in some cases).
But overall, the only real accurate way to do it is to add tracking/listening functions within the .swf object itself (which means you will need access to the .fla source file to add and re-compile to .swf). And you use ActionScript for that (Flash's scripting language). But you CAN make external js calls from within .swf object, if you need to pass info to js. But again, this involves putting code inside the .swf
Related
I am currently trying to write a script using javascript along side a bit of html and some css - but let's stick with Javascript as thats where, I think, my problem comes from...
In short what I want my program to do is these following points:
I have an iFrame in the main window of my program.
The iFrame is used to access a website (obviously duh :P)
There is a button outside of the iFrame.
That button will call a function when pressed by the user.
HERE'S MY PROBLEM:
I want that function to simulate the press of a keyboard key (in that case, a number key followed by the ENTER key twice.
The thing is, I need to 'simulate' these keypress inside the iFrame, so they interact with the website that is access through the iFrame.
In short, I can't seem to find a way to interact with the website in iFrame from outside of it. I would prefer a solution using pure JS but I'm fully aware that there would probably be a much simpler solution using Jquery. So I'm open to either one of them.
I don't think that pieces of my code would help as there is basically nothing coded so far, besides the main function and the basic layout of the page. I'm ready to redo the whole architecture of what I've done so far if needed.
Thanks for you help.
Yann
I have an asp.net-mvc website where there is a top section with a bunch of filter information and the middle section is a reports. I now have a few different report formats and I want to toggle between a few reports. I have it working by making them all partial views and loading them via ajax (to avoid loading the common info over and over again) but one issue i realized is that some of the different reports have different javascript that goes along with them. For now, I am loading up all of the javascript files in the main parent page but I realized that I am wasting a lot of resources by download and wiring up all of the jquery events even if i never actually view a report
Is there anyway I can pass some javascript along with downloading a partial view in asp.net-mvc so I only load this and wire up the events "on demand" as required (instead of always)
Of course you can. Just be aware that the effects of the code will stick around even if you later remove the code itself: any functions you defined will remain defined, any listeners you attached will remain attached (as long as their target elements persist)... so it would be a good idea to make a setup() and teardown() methods for the loading code, that you'd invoke from your controlling code, rather than just drop a bunch of code to execute as it loads.
However, I would say it would need to be a rather unique set of circumstances for me to employ this method; for most part, it would be much easier and efficient to just load all the code you need at once, to benefit from client caching if nothing else. Toggle the behaviour of your code, don't toggle the code.
After reading Marionette.Commands I am very curious to finding difference between normal functions and Marionette.Commands.
If you define any function, you can call that function wherever you want.
normal Function :
var normalFun=function(){alert("Normal Function")};
same way Marionette.commands also working like in the following way.
//creating instance for Application class
var myApp=new Marionette.Application();
//registering command
myApp.Commands.setHandler("functionName",function(){alert("This is just a normal function but way of defining as different in my point of view.")});
//whereever you want to call this command just run that command with corresponding name
myApp.Commands.execute("functionName");
What I am thinking, both normal functions and Marionette.Commands are same. If it is right then why did Marionette developers develop this Marionette.Commands concept?
To use a function, you need to either call it from the same scope, or have a reference to a containing object. This isn't the case for commands, so they allow for decoupling.
Say you want to change the color of the menu when a user clicks on some button in your app. You can define a changeColor function in (e.g.) the portion of your application that manages the header. Then, you can make the menu color change by calling (e.g.) myHeader.changeColor() from somewhere in your application. But as mentioned above, that means you need a reference to myHeader to be able to call its changeColor method.
As you develop your application, you realize that actually the menu itself is getting quite complex, and it makes more sense for it to change its own color directly (instead of having the header manage the color). Now you need to go in your application and change every instance of myHeader.changeColor() to myMenu.changeColor(). This is due to the coupling of the various bits of your application.
If instead you use commands, you would execute the command from the places that need to change the menu color, and you'd define the handler in the "header" part. Then when you decide to change your application design, you can simply move the handler so it's defined in the "menu" part. With this solution, you won't have to change the actual calls to change the menu color, because they're entirely decoupled.
With both solutions, you can change the menu color. But using commands allows for better decoupling and less work down the road. Of course, this doesn't mean you should use commands everywhere: adapt their use (or not) to your particular case.
They are the same. I mean everything is the same down the road (a function), always. Haha.
What's important is what you make out of it. So, in the end, it is just a matter of taste/professionalism (respecting patterns, conventions, etc..).
With the commands, you have everything in one place and only myApp is responsible for communicating between the modules/the controllers/the domains/whatever "functional end result" (to quote #David Sulc very good book: "Backbone.Marionette.js: A Gentle Introduction") of your application.
So long story short: In a big app, it makes sense to only pass around the myApp instance, and executes the commands from there.
Note: And that makes even more sense when you're using RequireJS.
That's cleaner, more structured.
Almost all web pages that I see designed to set the focus to an input box add the code into a body onload event. This causes the code to execute once the entire html document has loaded. In theory, this seems like good practice.
However, in my experience, what this usually causes is double work on the user, as they have already entered data into two or three fields and are typing into another when their cursor is jumped back without their knowledge. I've seen a staggering number of users type the last 2/3 of their password into the beginning of a username field. As such, I've always placed the JS focus code immediately after the input to insure there is no delay.
My question is: Is there any technical reason not to place this focus code inline? Is there an advantage to calling it at the end of the page, or within an onload event? I'm curious why it has become common practice considering the obvious practical drawbacks.
A couple thoughts:
I would use a framework like jQuery and have this type of code run on $(document).ready(.... window.onload doesn't run until everything on the page is fully loaded, which explains the delay you have experienced. $(document).ready(... runs when jQuery determines the DOM has been loaded. You could probably write the same sort of logic without jQuery, but it varies by browser.
I prefer to keep my Javascript separate from my HTML because it allows for a cleaner separation of concerns. Then your behavior is then kept separate from your document structure which is separate from your presentation in your CSS. This also allows you to more easily re-use logic and maintain that code — possibly across projects.
Google and Yahoo both suggest placing scripts at the bottom of the html page for performance reasons.
The Yahoo article: http://developer.yahoo.com/performance/rules.html#js_bottom
You should definitely place the script in the appropriate place if it means the correct user experience -- in fact I would load that part of the script (Used for tabbing inputs) before the inputs to ensure it always works no matter how slow the connection.
The "document.ready" function allows you to ensure the elements you want to reference are in the dom and fires right when your whole document dom is loaded (This does not mean images are fully loaded).
If you want you could have the inputs start out as disabled and then reenable them on document ready. This would handle the rare case the script is not ready yet when the inputs are displayed.
Well if you call it before whole page has loaded you really don't know if the element already has been loaded when you make your call. And if you make your call in pre-hand you should check if the element really exists even if you know it always should.
Then to make the call inline, which might seem ideal. But on the other hand it's really bad if a page takes that long to load that you can make several inputs during the loading phase.
Also you could check if input has been made etc.
Also it is possible to check if any input on page contains focus if($("input::focus, textarea::focus").length)... and otherwise set focus on desired input.
Use the autofocus HTML attribute to specify which element should initially receive focus. This decouples JavaScript and gracefully degrades in older browsers.
My coworker and I have encountered a nasty situation where we have to use an active X control to manipulate a web camera on a page.
Is it possible to assign a javascript event handler to a button in the active x control so that it would fire an action on the page when clicked, or do we have to create a button on the html page itself that manipulates the Active X Control and then can fire any necessary actions on the page?
Please just use an existing ActiveX control. Like Flash or Silverlight. Flash has built-in webcam support and is controllable via JavaScript. Silverlight doesn't have built-in camera support, but it's JavaScript integration is fantastic.
If you must write your own then fret not, it is trivial to get it to interact with JavaScript. You just have to expose the IDispatch interface.
For events, you need to learn about Connection Points.
Yes! You can throw events in C++/ActiveX land which makes the JavaScript code run an event handler function. I was even able to make an entire invisible ActiveX control (same color as page background) with no buttons or visual feedback that did all of its GUI work through JavaScript and CSS.
edit: Frank's advice is right on. Here's the link on scripting events.
My strategy was to call a C++ function called MyUpdate (which implements IConnectionPoint) when I wanted to force updates in the browser.
(Also, I made sure to pump Windows messages in the Fire_MyUpdate method because sometimes JavaScript code would call back into C++ land by calling methods on the ActiveX control; this avoids freezing up the browser and ensures that the JavaScript GUI stays responsive, e.g. for a Cancel button.)
On the browser side, the JavaScript code has the global variable referencing the object, followed by "::", followed by the method name:
function Uploader::MyUpdate()
{
// ... code to fetch the current state of various
// properties from the Uploader object and do something with it
// for example check Uploader.IsActive and show or hide an HTML div
}