I am using CCS to program a MSPFR6989 and I’ve debugged and the code is working but I can’t get variables or registers to come up. It remains blank. enter image description here
use double click onto your variables and choose watch expression. You can find your variables under expression from now. If it shows you its name but a red error message try step by step debugging, works for me everytime.
Related
I would like to know where is this error code located in the AOT. Would like to know the path to understand the structure and develop custom code.
Transaction has been selected, for settlement, although settlement type: none was selected
I generally use one of two methods to locate message strings.
Provided the cross reference is updated (it should be in dev) use the "Label editor" to to search for then string, see this answer.
Put a breakpoint in top of info.add method, disable CIL if needed, then rerun to get the error message invoking the debugger, see this answer.
I'm working with ASSIGN SESSION:DEBUG-ALERT = TRUE. and as a result, while testing a program I get an error message with following callstack details (only the first line):
--> USER-INTERFACE-TRIGGER my_own_window.w at line 587 (\\<official_build_server_directory>\my_own_window.r)
my_own_window.w at line 709 (\\<official_build_server>\<my_own_window.r)
...
As you can see, something's wrong with my window at lines 587 and 709, but:
While compiling the window files, some things happen which mess with the line numbers, and the mentioned line numbers are the ones from the compiled *.r files, which are different than the ones from the original *.w files.
In order to be sure about the line numbers, I would need a de-compiler, or at least a *.r-viewer (being based on an internal de-compiler).
It's not the r-code's you need to look into. It's the DEBUG-LISTING files. If you have the source-code execute:
COMPILE my_own_window.w DEBUG-LIST c:\temp\my-own_window.debuglist .
That file shows you the actual line numbers.
For future reference: so far Progress has not provided a decompiler. Any available decompilers at the time of writing this are 3rd party and also possibly not legal regarding Progress OpenEdge licenses.
You can also click on the 'Debug' button in that alert box, which will invoke the debugger which steps through an 'on the fly' debug-listing.
For the debug-listing on the fly to work, you will need to have the source files in your propath. The debugger will detect and complain if source files have changed after your code was executed.
And you will also need to ensure the debugger is enabled by starting proenv and then prodebugenable -enable-all
I have a table with different methods, for example, one of them is validateWrite, when setting Field A to value X, Field B and C has to be filled in.
Suddenly (without changing code, I have compared the code with the test enviroment, it does work there) the validateWrite has stopped working.
I have tried to recompile the table, but that did not work.
Any idea why it suddenly (without making other modifications in this enviroment, or generating a CIL) stopped working and what i can try to solve it?
If some piece of code is calling table.doInsert(), it skips the validateWrite() method.
If the environments are truly identical, then I would try closing your AX client and deleting your user caches (see http://dynamics-ax-live.blogspot.com/2010/03/more-information-about-auc-file.html) where you delete all of the *.auc files located at C:\Users\[Username]\AppData\Local
In addition to what that tells you to delete, I'd also remove the *.kti file and all of the files & folders inside of C:\Users\[UserName]\AppData\Local\Microsoft\Dynamics Ax
Then open AX, see if the problem still exists. Then full system compile, CIL build, and delete your usage data.
The preferred route though would be to just drop a breakpoint in and debug the code to see what the execution stack is.
I have downloaded the Alexa Skills online tutorial found at:
https://github.com/amzn/alexa-skills-kit-js/blob/master/samples/reindeerGames/src/index.js
and followed (I think) all of the instructions in the tutorial found at:
https://developer.amazon.com/public/community/post/TxDJWS16KUPVKO/New-Alexa-Skills-Kit-Template-Build-a-Trivia-Skill-in-under-an-Hour
This is meant to be a tutorial for first time Alexa Skills developers. My question is, I get this error message once I hit the "Save and Test" button:
errorMessage": "Exception: TypeError: Cannot read property 'application' of undefined"
Does anyone know what the above error means or how to get rid of it?
Thanks v much.
This looks like a javascript error telling you that you are trying to use a property named application on an undefined variable.
JavaScript assigns the value "undefined" to any variable that you use but haven't set yet.
There are a several ways that you can debug problems in your Lambdas. Perhaps the easiest is to review the Logs. To do this:
Go to the Lambda console (where you upload your code to Lambda)
Select the Monitoring tab
Select "View logs in CloudWatch" (in the upper right)
Review the latest log, looking for a reported error in one of your files (typically index.js) and specifically the line number. That should help you find the error.
Note that the time stamps will be GMT, so probably won't match your actual time. This can be confusing if you have multiple entries. But the minutes should match, helping you verify that you're looking at the correct log entry.
A more advanced, and quicker way to debug Lambda problems, is the include a "test" request, and run this each time you upload code to Lambda.
To set this up:
Run one of your defined utterances in the ASK test page under the "Service Simulator" section.
Copy the code displayed below that in the "Lambda Request" section.
Now switch to the Lambda console for your Lambda function
Click the down arrow in the Actions button and select "Configure test event"
Paste the request you copied above into the text field
Click Save and Test.
Now each time you upload new code to Lambda, you can select "Test" and the request that you just saved will be run.
And best of all, the console log will be displayed in the lower right corner, saving you from having to switch to the logs and refresh to view them.
I have an Xcode project I've been working on for months. I've never had a problem with NSLog, but after upgrading to Xcode 4.2 nothing will log to the console. I even tried throwing this in viewDidLoad:
- (void)viewDidLoad
{
[super viewDidLoad];
NSLog(#"Can anyone hear me?");
And nothing. Is anyone else having this problem or know a solution?
Well, this is embarrassing. The console got deactivated somehow and I was actually watching the variables window. Pressing Shift + + C did the trick.
Many thanks to Robert King on this thread:
https://devforums.apple.com/message/565880#565880
This is a bug of Xcode8 + iOS10, we can solve it in this way:
When on simulator, add the Name OS_ACTIVITY_MODE and the Value
Variables disable and check it (Product -> Scheme -> Edit Scheme -> Run -> Arguments -> Environment).
When on device, only add OS_ACTIVITY_MODE and check it（don't add the Value). You'll see the NSLog in the Xcode8 Console.
In iOS10, a lot of system logging is displayed on the console. This can be disabled by including the OS_ACTIVITY_MODE = disabled in the Run Arguments for your scheme
However for iOS10, NSLog messages will not be displayed anymore.
In lower iOS versions the messages will still be displayed. So maybe for most test cases you can use a lower iOS version.
Otherwise you can include a Swift function which prints (print function) your text, this is working okay in iOS10.
Tested on iOS10.0.2 and iOS9.3
My issue is that I have Debugger Output selected. Once I changed it to either All output or target output NSLogs appear fine.
In case this confuses you its on the left of the Debug area.
I had the same issue.
The trick is to search and remove the below mentioned line from the project.
#define NSLog(...)
Search the entire project and remove it.
I just experienced this, so here's another thing to check.
-> Make sure you don't have anything typed in the Filter field below the Log Output. So, in my case I was searching for a term in the logger and forgot to delete the searched terms out of the Filter text field. DOH!
My issue was that I'd accidentally severed the referencing outlet from App Delegate (delegate - file's owner).