Captivate 8 RGB entry bug

Does the Captivate 8.0.1.242 patch address the bug with entering RGB values in the Color Picker? Don't see it specifically mentioned in the patch FAQ, thought I'd double-check.
Thanks!
Tim

Yes, Tim, I checked it right away.

Similar Messages

Captivate 6.1 Javascript bug / subscription edition

Hello all,
I'm working on a SCORM 1.2 compatible eLearning project on Captivate 6.1.0.319 (subscription edition), and I've just come across the bug described very precisely here:
http://www.youtube.com/watch?v=Vq9K9lvq-5I
and here:
http://www.cpguru.com/warning-adobe-captivate-6-and-javascript-bug/
Basically, any javascript used in the project would break the SCORM compatibility, either sending wrong completion information to the system, or in my case, also shutting down the eLearning module and also closing the window. This problem occurs only in IE, as other browsers seem to work fine.
My target group of users is a corporate environment, in which IE is the #1 platform; it's unrealistic to ask for a browser update, so I have to find a solution to be able to publish the project correctly. The same blogger who uncovered the problem wrote that it's possible to receive a patch from Adobe which consists of an updated version of the file Mainmovie.swc to swap in one of the program's directories (more info here: http://www.cpguru.com/fix-for-the-adobe-captivate-6-javascript-bug/ ).
The problem is that the supposed fix (which you have to request via email and it's not directly downloadable), is said to be available only for Captivate 6.0.xx and not for the 6.1 Subscription edition.
As my project contains a lot of drag and drop interaction, I cannot afford to downgrade to 6.0 to try to use the patch, and I was wondering if somebody has had the same problem and can help out.
In detail, I only use javascript in one slide to simulate a random display of rollover images (a button calculates the current position of the playhead and jumps to a random point of the slide, chosen from an array of predefined frame numbers; at every 'stop' there is a different rollover image and a button that makes the playhead jump again to display another 'random' image).
I was wondering if there is any way to reproduce this behavior not using javascript, so that if there is no fix (I'm obviously in a very tight deadline...), I can get around the problem by avoiding javascript altogether.
Thank you very much for your help!
n

You can open 6.1 files in Cp version 6.01. So that IS an option, though albeit probably not a very palatable one if you've just upgraded everyone around you to 6.1.
If your main reason for developing in 6.1 was the drag and drop interactions, you may not have been aware that there have been AS3 widgets available to do drag and drop in Captivate since version 4. Those widgets are also now compatible with all Cp versions up to and including 6.01 and 6.1.
More information here:
http://www.infosemantics.com.au/adobe-captivate-widgets/drag-and-drop/which-adobe-drag-and -drag-and-drop-widget-comparison
Free trial versions downloadable here:
http://www.infosemantics.com.au/adobe-captivate-widgets/download-free-trial-widgets

IPhone Keyboard Entry Bug

When using "My Account" (bookmark), there's 2 field to insert.
One is "Wireless Number" and the other one is "Password".
I found out I mistyped one of the number of "Wireless Number"
after typing in 10 characters.
That field is 10 digit(phone # with area code) and I couldn't insert anything.
I mean even "backspace"(erase) didn't work.
Which means I couldn't change anything after typing in 10 characters.
I think it's definitely iPhone keyboard entry bug.
Please fix it ASAP.

Please call 1-800-My-iPhone to report this issue. A friendly Agent can log this and get it to the proper department.

Captivate 8 RGB bug?

I'm trying to use RGB values to edit the color of an object. I select the object, open the Fill property, and choose the Color Picker. Regardless of what numbers I enter, the color results in dark gray or black as I tab through the values.
Hex code works fine, but if I enter #FFFFFF and it shows white, without entering any additional numbers just tabbing through RGB, it turns to #020202.
Anybody else have this problem, or is my Mac being surly?

Agreed, I wish colors were better linked throughout. I do think it's a step in the right direction, though. It's clunky, but not as much as it was!
In line with color, I also wish some design elements could be brought more under the rest of the Adobe products. I find myself constantly using keyboard shortcuts I use in Photoshop or Illustrator, only to get the Error Noise of Doom from the OS. Just little things, like the Zoom tool and Hand tool, would be really helpful.

Captivate 6 Text Entry Events Do Not Pass

I am a long-time user of Captivate going back to version 2. I've created a simulation course with numerous text entry events that do not validate correctly. I am typically using the TAB key to validate the text entered. I have several lessons where everything works fine, but many that have problems.
Typically when TAB is used at the end of a key press, you will see focus shift to the first button on the Play bar - and this does not cause any problems. I see this behavior on the events in my course that work. However, for the ones that do not work, I see the focus shifting to the Address Bar and the event will not pass.
The only workaround I have employed is to use On Focus Lost: Go to Next. This is not a great solution because the text no longer validates with this setting. These events will pass no matter what is entered.
I would really appreciate your help with this! My course is due soon. I would be happy to provide more information or upload my file for your inspection. Thank you!

For anyone who might be experiencing the same problem and looking for an answer - this is still 100% broken in Captivate version 6. None of the fixes discussed in the above referenced thread work. I tried playbar widgets, editing the playbars in Flash. No luck.
Adobe just moves forward from version to version not fixing the bugs they create in prior versions. That's your incentive to upgrade, folks.
Best workaround I can offer is Use ENTER as your validation keystroke. It doesn't have the same problems associated with TAB. Good luck!

RGB printing bug still not fixed with 6.0.4

I guess I should not be surprised.
After three major releases of OSX and 20 updates and two major version and 8 updates of Indesign the monitor profile is still being introduced into the RGB printflow.
What the HELL does it take to get this bug fixed?
And, yes I know you can use "Print as Bitmap" or "Fast Graphic Process" in the Canon drivers to work around this problem.
Just maybe if IDCS5 uses the Cocoa print path that PS and LR now use it will be fixed then.

Anyone know if CS5 has fixed/addressed this problem?

Captivate 7 - The Exit Bug and a Solution

Hey Everyone,
I wanted to take a second and share some good information I found in regards to SCORM and the Exit functionality in Captivate 7. Below is the blog post that shows how to make the Adobe Exit functionality "SCORM Compliant" and solved my issues when uploading my project and getting them to exit. Hope this helps
Captivate 7, Exit Bug and a Solution
Several of our Inquisiq R3 users have alerted us to the fact that courses developed with Captivate 7 published to HTML5 and SWF do not close properly when using the “Exit” button, forcing the user instead to manually close the browser window by clicking the “X” in the upper-right corner of the browser window.
Through our investigation into this issue, it appears that the process that Adobe has implemented when clicking the “Exit” button is to simply attempt to close the content window and rely on the LMS to capture and commit the session data. Nowhere did we see that the content was actually calling the “LMSFinish()” [SCORM 1.2] or “Terminate()” [SCORM 2004] methods in the LMS’s SCORM API to commit the lesson data to the LMS as required by the SCORM specification.
Adobe uses their own defined function, “DoCPExit,” to close a lesson window. This method contains a “window.close()” call and additional logic to “bubble up” the command through the frame parents (if they exist and also contain the “DoCPExit” method - presumably because they would also be Adobe-published content files within your package).
There are several flaws to this approach.
By not calling “LMSFinish()” or “Terminate(),” the content is, by definition, not SCORM conformant. Part of the minimum requirements for conformance are that the content calls the initialization method “LMSInitialize()” in SCORM 1.2 or “Initialize()” in SCORM 2004 and the termination method “LMSFinish()” in SCORM 1.2 or “Terminate()” in SCORM 2004. The LMS is not required to clean up the data left behind when the content fails to make this call. So if your LMS doesn’t take this additional step (of setting ‘LMSFinish’ or ‘Terminate’ if the lesson does not), your data will be completely lost…i.e. no record of you taking the lesson will be recorded.
The call to close the browser window will fail if the LMS is running the content within a frame or iframe. Since the SCORM specification allows content to be launched in frames or iframes (in addition to new browser windows), lessons need to be able to accommodate this scenario. Even with the “bubble up” logic, once the call reaches the top most content window, and the next parent window in line is the LMS container page, the call will no longer be passed and a “window.close()” call will be fired within the framed page. When this call is made, nothing will happen as a framed page cannot close the browser window using this command. Through our investigation, we’ve learned that at least 4 other well-known LMSs have experienced this particular issue.
Ironically, the solution that we’ve discovered is not only SCORM conformant, but also very simple and follows what we would consider to be SCORM “best practices”. The foundation and logic for the solution is already contained within the published Captivate files (and it is the same solution whether you publish to SCORM 1.2 or SCORM 2004).
We simply modify the “DoCPExit” method that is contained within the “Utilities.js” file to call the “Finish()” method. Just replace all the code appearing between the “{“and the “}” as you see here:
function DoCPExit(){ Finish();
The “Finish()” method that we have inserted is, as mentioned, already contained within the published Captivate files and contains the logic to properly set the exit parameters and correctly identify whether the content is SCORM 1.2 or SCORM 2004; it will therefore make a call to the correct close method (“LMSFinish()” or “Terminate()”) accordingly. Once the LMS has received this command, it should take care of removing the content properly, leaving no need for any “bubble-up” logic or window close calls within the content code.
Overall, if the lessons you develop with Captivate 7 work as expected and required in your LMS, there is no need to implement this change. However, if your lesson’s Exit button is not working as it should, and/or you are losing progress and status data when closing the lesson, the fix described here should resolve all those issues.
The biggest issue here is that since we’re changing published code, the next time you update and publish that same Captivate project, you have to remember to change that published function code AGAIN, as Captivate will simply publish the default code.
We have been in touch with the Captivate team to discuss this problem and they are investigating. We would hope a patch to address this flaw would be released in the near future
All credit of this fix goes to http://blog.icslearninggroup.com/2013/10/captivate-7-exit-bug-and-solution.html

Try clearing out your project cache (Preferences > General > Clear Cache) then republish using the option to Force Republish All Slides.
If that doesn't resolve the issue, you may be seeing the early stages of project file corruption. Check the suggestions in this post about troubleshooting issues where you may need to copy all slides to a new blank project shell to try and strip out corruption:
http://www.infosemantics.com.au/adobe-captivate-troubleshooting/basic-troubleshooting-tech niques

Calendar entry bug

The latest E72 firmware brought another bug. Creating a calendar entry by just starting to type in the month view is no longetr possible for entries starting with a "u" or a "j" (* or #).... Can someone verify please?

Not sure what you mean... You have to press the "n" first to add a new meeting... After that, works fine for me... Try to restart the phone...

LR Preferences - Data Entry Bug?

Can anyone supply me with a list, or cite to a list, of preferences in the file "com.adobe.Lightroom2.plist?" I am asking this because no one answered my question about the space bar zoom toggle problem I get from time to time. It stops working every once in a while and I think it happens when I've inadvertently typed a letter that shuts off this function when entering a City or Country name in the Metatdata and the text box de-selects unexpectedly (allowing the letters I'm typing to be used to trigger commands rather than enter text). It starts working again when I substitute my most recently saved backup Preferences file, leading me to believe that I've somehow changed a preference by whatever letters I've entered (not illogical, but not proven). Since I usually don't notice this for a while, I'm not sure what names I've typed so I can't figure out what letters were entered. This is not a biggie but is annoying though it has the side benefit of making me learn things about LR I have chosen to ignore in the past. Another question is whether the de-selection of the City or Country field while I'm typing is a bug or just a way to make me use the accumulated names pop up I've previously entered in these fields with LR presuming this is a good shortcut? iMac 24;3.06 ghz;Snow Leopard.

Hi,
R&D has researched this issue with the pot object. They have edited the pot object to try to fix this problem. So I will post the fixed pot CBX file on our FTP site. We would like it if you could please test this with your applications and ensure that it works okay. If it does work, then we will integrate this new pot CBX in our next fix.
So its absolutely imperative that we get feedback from you on this fix and whether it works well.
To get this fix, go to:
ftp://ftp.ni.com/outgoing and download the file called pot.cbx. Then copy this file to "C:\Program Files\National Instruments\Lookout 6.0". The last part may be different based on your version of Lookout. NOTE: Backup the existing pot.cbx file to another folder in case you need to revert back. This fix has been created for the latest Lookout version (v6.0), but I have tested it successfully in v5.1 and v6.0. We always implement fixes on the latest version of our software, but I think it should work with your version too.
Once this new pot.cbx has been verified by you, we will implement it in our fix. I would recommend re-downloading the fix when it releases. This is why I'm placing the pot.cbx file in the FTP site as a temporary download location.
Thank you for all your help!
Anu Saha
Academic Product Marketing Engineer
National Instruments

Adobe Captivate 6: Text Entry Box

When a student add text into a Text Entry Box on slide one, how can his/her text be shown in following slides (slide2).
Example: each user will have the ability to put his/her own text in the Text Entry Box on slide one.
Can the text be temperaly stored and shown again?
Thanks to help me out on this :-)

Hi Neil, I hope you don't mind me adding some tips? Do not type in the variable, but insert it in the text container (can be a shape as well, not only a caption) using the X button in the Format accordion of that text container. Variables are case sensitive, and that will avoid possible typos. Really I discourage always typing in the variable name between $$
Another tip: TEB's have an automatically generated associated variable, that has the same name as the TEB (I dislike that a lot, because mostly you cannot use the same name for two different objects). You could also use your custom name, there is another X button in the TEB properties, next to that generic name.

Captivate Alt-Key Freeze bug

I have read other posts on this question.
Problem:
When using Captivate 5.5 or Captivate 6 on Windows 7-64, and recording AI CS5.5, AI CS6, PS CS5.5, and PS CS6 I get a "freeze" whenever I hold the ALT-key. (Which is very often) It occurs under any video circumstance, FMR, Demo etc.
This happens on mutliple machines. I have a Wacom Intuos 3 tablet, but this happens regardless of whether it is plugged in or not/services are running. (I had thought maybe it was an issue with the Wacom)
I have seen that others have reported this, but does anyone have a workaround?
Jim

I am sorry for the delay in responding. Thank you for your response.
I work in both situations, where there is a network drive, and where there is not. The issue exists in either situation. I moved the cache to a different drive - still froze. I moved it to a different folder on C drive and it still froze.
The drive is 0% fragmented.
The drive has 45gb free space.
I removed Temp files and did a CCleaner to remove other temp files.
In FMR, the problem persisted.
The first time I used the recorder in Auto Mode, I was able to make a simple Alt-Drag copy of an object on the artboard. However, when I tried to move a second object, the pause/freeze happened again.
I just don't get it. A cheap screen recorder (Screen Recording Suite from Aipowersoft) works perfectly. It's editing tools don't work as well, but at least I can get a smooth screencast.
Thoughts? Is their a command line to create a debug log?
Jim

New Calendar Entry bug

Z10 10.0.9.348
With No Apps running, click on Calendar icon, click on Add button, set focus to subject field and enter text, then tap on "Starts (date and time...)"
As soon as I click on the "Starts..." input field, it kicks me out of the calendar.
Work around - only enter the subject field and then save it and come back and edit it later on.

It's definitely a bug in that version of the OS. Contact Telus, have them escalate you to BlackBerry support with BlackBerry. The more reporting of the issue the faster you'll get the update.
We're still not really sure how the update process works on BB10...whether carriers control it as in the past or whether BlackBerry controls it, similar to Apple.
1. Please thank those who help you by clicking the "Like" button at the bottom of the post that helped you.
2. If your issue has been solved, please resolve it by marking the post "Solution?" which solved it for you!

Bug report: Controls in the Data Entry property page reset when using relative time

Create a blank VI.
Drop a numeric control.
Right click and select "Display Format".
Change to a relative time.
Switch to the "Data Entry" tab page.
Uncheck the "Use Default Limits" boolean.
Try changing the values and you will see that they return to their previous values (inf, by default). This persists even after pressing OK and opening the dialog again. It looks like the values are held in a cache and put back into the controls, since if you change a page and go back to the limits page, it shows the correct values. I also managed to get it to display the values using the correct format (relative time), which I assume is what it should be doing.
This is in LabVIEW 8.6.
Try to take over the world!
Attachments:
Relative Time Data Entry Bug.vi ‏5 KB

I spent some time playing around with this in 8.6.1, and at this time do not consider it a bug - unless there is something I completely missed.
When you set to relative time, the inputs for data entry are expecting HH:MM or HH:MMS, depending on which display setting you chose. Typing a '7' is undefined - does the user mean hours? Minutes? Seconds? Parsecs ?
Once we type in a value that matches the format and we get the display to change, it is true that from now on if we type '7' in the field, it will automatically coerce it to 7:00, if we type 36 it coerces to 36:00. If we type 7.5, it does not change the value at all. I think at this point, the user knows what is going on, so this behavior is acceptable. After accepting the changes and re-opening the properties window, the limits are persistent.
I was not able to reproduce typing a '7' in the limit, having it automatically coerce back to '-inf', then going to a different tab or clicking ok, and coming back and seeing it as 7:00. It was still '-inf'. If you have some more details on this, maybe I can reproduce it, but from everything I tried, users are be able to enter values and these values are saved.
Edit - I am aware of the other forum post and the CAR filed there...
Message Edited by Robbob on 03-03-2009 11:20 AM
Rob K
Measurements Mechanical Engineer (C-Series, USB X-Series)
National Instruments
CompactRIO Developers Guide
CompactRIO Out of the Box Video
Attachments:
2009-03-03_105522.jpg ‏51 KB
2009-03-03_105336.jpg ‏58 KB

Javascript bug and random frames: alternative solution?

Hello all,
I'm working on a SCORM 1.2 compatible eLearning project on Captivate 6.1.0.319 (subscription edition), and I've just come across the bug described very precisely here:
http://www.youtube.com/watch?v=Vq9K9lvq-5I
and here:
http://www.cpguru.com/warning-adobe-captivate-6-and-javascript-bug/
Basically, any javascript used in the project would break the SCORM compatibility, either sending wrong completion information to the system, or in my case, also shutting down the eLearning module and also closing the window. This problem occurs only in IE, as other browsers seem to work fine.
My target group of users is a corporate environment, in which IE is the #1 platform; it's unrealistic to ask for a browser update, so I have to find a solution to be able to publish the project correctly. The same blogger who uncovered the problem wrote that it's possible to receive a patch from Adobe which consists of an updated version of the file Mainmovie.swc to swap in one of the program's directories (more info here:http://www.cpguru.com/fix-for-the-adobe-captivate-6-javascript-bug/ ).
The problem is that the supposed fix (which you have to request via email and it's not directly downloadable), is said to be available only for Captivate 6.0.xx and not for the 6.1 Subscription edition.
As my project contains a lot of drag and drop interaction, I cannot afford to downgrade to 6.0 to try to use the patch, and I was wondering if somebody has had the same problem and can help out.
In detail, I only use javascript in one slide to simulate a random display of rollover images (a button calculates the current position of the playhead and jumps to a random point of the slide, chosen from an array of predefined frame numbers; at every 'stop' there is a different rollover image and a button that makes the playhead jump again to display another 'random' image).
I was wondering if there is any way to reproduce this behavior not using javascript, so that if there is no fix (I'm obviously in a very tight deadline...), I can get around the problem by avoiding javascript altogether.
Thank you very much for your help!
n
(crossposted on the general Adobe Captivate forum)

I don't have a solution for you, but I want to compliment you for a great post. I wish others would follow your lead, and include the information about their system, the problem, the steps already taken, etc.
Have you tried creating a new project, with a new HDV sequence, and editing a short timeline as a test to see if it's a problem with that one timeline or not?

Recorded Text Entries are displayed unclean in PDF Output

I'm creating currently a screencast with Captivate 7. Within this screencast, I have to type an adress into the adress bar of Internet Explorer. Captivate records this entry automatically in Full Motion, this works good.
But I had to note, that the output in PDF destroys the text entry. During the entry, the textcursor appears after every single sign and the entry becomes unclean.
This problem appears also, when I'm scaling the project. Then it appears in all outputs.
Does anyone have the same problem and a solution for this problem?
This picture shows the problem in PDF Output.

Try turning off all compression options in Preferences > Project > SWF Size and Quality. Also try setting quality of any affected slides to High 24bit or Optimized. Then republish and test again.

Captivate 8 RGB entry bug

Similar Messages

Maybe you are looking for