its my first time working with pepper and i am working locally on my computer with no connection to a real pepper. I am trying to follow the steps from http://doc.aldebaran.com/2-8/getting_started/helloworld_choregraphe_dialog.html#helloworld-choregraphe-dialog .
I am getting the error messages:
[WARN ] behavior.box :getService:16
_Behavior__lastUploadedChoregrapheBehaviorbehavior_193854592:/Set Language_2: ALSpeechRecognition is not available, language setting
cannot be applied to recognition.
[ERROR] behavior.box
:onInput_onSet:49
_Behavior__lastUploadedChoregrapheBehaviorbehavior_193854592:/Set Language_2: Language English could not be set for one or more
services.
I tried following all steps in the tutorial and removed the german language which i originally intended to use. I have linked the modules correctly as well and would be really happy if you could tell me which mistake i need to fix in order to get it to work.
Thanks in advance and best regards
You most likely forgot to define the projects language.
Click on properties (on the left side of choregraphe, next to the blue cube) and then, on the window that just opened, click the languages of your choice on the right column. Since you are here, don't forget either to give an application id.
Setting the language has no effect on a virtual robot, because it as no TTS or ASR.
You can safely ignore the error or catch it, for instance by adding an onError output wired to the rest of your behavior.
Related
I've been trying to implement a connection point sink for a third party COM component using MFC. I've developed some COM components before, though connection point sinks is not something I'm well versed in. After banging my head against a wall for a while, I decided to go back to basics and found this Microsoft example:
https://support.microsoft.com/en-us/kb/183599
It seemed the most similar to what I'm trying to do. I attempted to reproduce the example exactly as described. Although my MS Word version is 2010, the referenced interfaces still appear to be valid. I dutifully followed the instructions, literally cutting and pasting the code into my own project and only having to make adjustments for wide character strings. After compile, I can launch the word app and quit it, but I don't receive the connection point events, which after all was the whole point. I thought perhaps the problem was with the function dispid, so I attempted to add DISP_FUNCTION_ID entries into the Dispatch Map; but that just leads to an assertion on oledisp1.ccp line 549 which turns out to be in the CCmdTarget::GetStackSize function.
I'm sure this is dumb simple, but I just can't get it to work. Can somebody please help me figure out what is missing from the example? Thanks.
Figured it out. I was on the right track adding the DISP_FUNCTION_ID macros to my Dispatch map, however I had stupidly used VT_VOID instead of VT_EMPTY which was caused the runtime assertion.
What does it take to build a Native Client app from scratch? I have looked into the documentation, and fiddled with several apps, however, I am now moving onto making my own app and I don't see anything related to creating the foundation of a native client app.
Depending on the version of the SDK you want to use, you have a couple of options.
Pepper 16 and 17: use init_project.py or use an example as a starting point
If you are using pepper_16 or pepper_17, you will find a Python script init_project.py in the project_templates in the SDK. It will setup up a complete set of files (.cc, .html, .nmf) with comments indicating where you need to add code. Run python init_project.py -h to see what options it accepts. Additional documentation can be found at https://developers.google.com/native-client/pepper17/devguide/tutorial.
Pepper 18 and newer: use an example as the starting point
If you are using pepper_18 or newer, init_project.py is no longer included. Instead you can copy a very small example from the examples directory (e.g., hello_world_glibc or hello_world_newlib for C or hello_world_interactive for C++) and use that as a starting point.
Writing completely from scratch
If you want to write your app completely from scratch, first ensure that the SDK is working by compiling and running a few of the examples. Then a good next step is to look at the classes pp::Module and pp:Instance, which your app will need to implement.
On the HTML side, write a simple page with the EMBED element for the Native Client module. Then add the JavaScript event handlers for loadstart, progress, error, abort, load, loadend, and message and have the handlers write the event data to, e.g., the JavaScript console, so that it's possible to tell what went wrong if the Native Client module didn't load. The load_progress example shows how to do this.
Next, create the manifest file (.nmf). From pepper_18 and onwards you can use the generate_nmf.py script found in the tools/ directory for this. If you want to write it from scratch, the examples provide examples both for using newlib and glibc (the two Standard C librares currently supported). See hello_world_newlib/ and hello_world_glibc/, respectively.
If you haven't used a gcc-family compiler before, it is also a good idea to look at the Makefile for some of the examples to see what compiler and linker flags to use. Compiling both for 32-bit and 64-bit right from the beginning is recommended.
Easiest way is to follow the quick start doc at https://developers.google.com/native-client/pepper18/quick-start, in particular steps 5-7 of the tutorial ( https://developers.google.com/native-client/pepper18/devguide/tutorial ) which seems to be what you are asking about.
We're using MFC data exchange to validate some data and we're having some problems. We're using the DDV_MinMaxFloat call to ensure that edit boxes in various parts of the application contain floating point numbers within a specified range. When using this validation if a value is entered out of range a dialog is automatically displayed to the user indicating that the value must lie within the range specified. This has been working correctly whilst running the application in debug however when building a release we are getting problems. The validation is still performed in release mode however the message box displayed to the user is blank.
I've tried the usual forcing a rebuild, deleting old resource files and deleting precompiled header files but this continues to happen in release mode. Has anyone come across this before? Are there any obvious things to look for?
I should also add that this application is over 10 years old, so obviously has been working correctly before. Somehow something has gone wrong in the last few weeks to cause this.
Those messages will come from MFC's resource strings. There might be some conflict with your own resources. Check to make sure your resources adhere to Microsoft's guidelines TN020: ID Naming and Numbering Conventions.
Pay particular attention to this bit:
MFC's internal framework implementations reserve two ranges: 0x7000
through 0x7FFF and 0xE000 through 0xEFFF.
Somehow something has gone wrong in the last few weeks to cause this.
Since your application worked fine a few weeks ago, it should be easy: check out the last working version from your revision control system and compare it with the current version. Or try to narrow it down to the first revision which does not work any more.
Check with Spy++ if there are controls on the message box that is displayed and if the text on them is blank, or if there's no controls on them at all. If the text is empty, you'll have to check the resources or the way the messagebox is called/created. Otherwise it may be something like resource being set incorrectly and the message assuming it can read its resource strings from ::AfxGetResourceHandle(). Note that this is a very easy error to make - it's a global handle that can be changed everywhere (including in dll's that you have no control over) so changes in remote parts of the code that at first sight seem unrelated may trigger it.
All of a sudden I'm getting over a hundred warning messages of that sort out of XCode build (that used to build without any warnings), but, curiously, when you look at the connections in Interface Builder there's no problem, buttons that are reported to lack connections work fine, and in every other way the application seems normal.
It's happening with several different view controllers and XIBs, some of which have some some stuff in common, but one which is entirely different from the others, with no includes in common, no common interfaces (other than Apple's), etc.
I tried clean, and I tried deleting the entire build directory, to no avail. Looked for files that may have gotten dragged out of place in the XCode file listing, but nothing obvious.
Any ideas?
Solved: Apparently someone in our group is using a later version of IB and checked in the XIBs. They're semi-incompatible with 3.2 until they're edited once, then the warnings go away.
I have a Managed C++ WinForm that suddenly stopped showing in the VS 2005 designer. The error it shows is
Could not find type 'int'. Please
make sure that the assembly that
contains this type is referenced. If
this type is a part of your
development project, make sure that
the project has been successfully
built.
I don't even know where to start with this one. Does the designer only access the InitializeComponent(void) method when rendering the form? So my question is: where do you start troubleshooting designer errors?
EDIT: I forgot to mention that this code builds and runs perfectly. It only shows an error in the windows forms designer.
This is troubleshooting for C# but I'd assume a couple of the points mentioned here would help.
What's the state of play with "Visual Inheritance"
This is usually caused by a syntax error somewhere in the code that causes the designer to be unable to run the form to render it. The best method for this is ofent sadly just reading the code looking for the problem extra brace, missing string etc. The good news is that it is most likely easy to find since you know that it preceeds the INT in the error message.
Some possibilities:
* I cause this usually by accidentally hitting the keybaord and putting some extra characters at the top of a file
* Extra braces that make the class uncompilable - missing quotes, semicolons
* Something typed at the top that messes up a common include/using statement
Diagnostics
* Sometimes you can find this by dogin a build and seeing what lione is flagged with an error and then looking around it.
* More often then not I have to just open the source file and scan through it looking for the problem.