If you've got, or get an Evo subscription, then that section of the forum has a lot of information dealing with these advanced ideas.
I imagine that cloning is a rather niche requirement and an advanced feature to add to Opus for an initial release. You can clone DOM nodes but this may well open a can of worms that require resolving. Just web search for JavaScript + cloneNode but this really is just the first step and really relies on what you're building. Again depending on what you're building, I'd be more inclined to blend the Opus HTML5 output with (for example) JavaScript or jQuery that handled that aspect of the application. This works well on the small scale, such as list box solution used by Jan (in Evo), but could be scaled to solve a cloning (though cloning isn't necessary with HTML) problem.
Yes, the background of the Text Input box remains solid. If you look at the HTML code, you'll see that as with most elements, DW style the element using SVG and where an actual HTML element is required - such as the INPUT element used for entering text, it's part of a large group of elements. Because of this the parent frame that uses the value in Opus that controls the background is not the same as the HTML INPUT element which by default has that solid white background. It's actually one of the first problems one of my clients needed fixing - so it is possible. Use JavaScript or jQuery to locate the INPUT element and then CSS styling remove the background.
The draggable problem likely occurs because the drag functionality is taking priory over the text input focus. It does seem like something that shouldn't happen so contact DW, but you can also fix it yourself by adding a left click to the Text Input Box and then using JavaScript and the .focus() function to solve this problem.
No wait won't work. Again Evo has a discussion on this as I explained it Stephen and how you need to work around the problem. Because everybody using script in HTML5 should understand this, here's a brief analogy:
JavaScript is single threaded. This is much like have just one queue in the supermarket. Every shopper must join the same queue and will be served in order. The first person in the queue gets served first, etc, etc.
If the first shopper in the queue has a massive overflowing trolley of food to scan and pack and all the other shoppers in the queue have a couple of items in their baskets, they must wait their turn.
JavaScript works in the same way. So imagine what would happen if rather than doing their shopping, one of the shoppers just stood at the checkout and waited... In JavaScript terms, lots and lots of processes can take place in a single second - so imagine what happens if you could put just a one second delay in that system - everything stops! Good JavaScript breaks everything down into smaller process to keep that queue flowing.
This leaves the question of what happens if I need something to to occur at a later time or at a timed interval? This is where browser events come into play. They are outside of that queue and can be triggered at any time. For example:
Code:
window.setTimeout("javascript function",milliseconds);
If I use a setTimeout, the browser keeps track of the delay and triggers the named function when that delay is complete. Then that process is added to queue and when it reaches the front, is processed.
Delve into the Opus.js script and you'll see how DW use this process with the setInterval timer event to control the sequencing (and delay) of actions. It does come with an implication though:
If you trigger a timer event frequently enough, when the named function is called and the process added to the queue, there may already be too many other processes in the queue for your functional call to be processed at the correct time.
Mack
https://twitter.com/imsmackavi
Login
FAQ
Search
