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
Related
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.
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.
in prokb,its mentioned
In 10.0B02 and above, the client session startup parameter -noincrwarn was reintroduced
to allow the selective suppression of the above four warning messages ONLY. Since the
execution of the 4GL statement: SESSION:SUPPRESS-WARNINGS = YES. suppresses ALL warning
messages during the session.
Where and how could i set i this startup parameter -noincrwarn to suppress this warning
message?
"SESSION:SUPPRESS-WARNINGS = YES." doesn't do much of anything useful. Or at least it didn't the last time I tested it.
The -mmax warning is harmless. It is a "soft" limit that is dynamically allocated and expanded as needed. You can ignore it. Or if the .lg file entries really bother you, you can simply increase it to a reasonable value. I routinely set it to 8192 for character sessions, 32768 for Windows. The default, as JensD says, is ludicrously low.
Startup parameters, such as -noincwarn, can set in a number of ways:
1) Via the command line. If your application starts via a script it will eventually invoke progress via "pro", "mpro", progress, prowin32, proapsv or some other executable (you can potentially link your own objects and create custom executables...) The command line that invokes Progress will have a number of parameters. You could add it there. Windows example:
#echo off
set DLC=\Progress\OpenEdge
%DLC%\bin\prowin32 -db mydb -p start.p -noincwarn
(On windows it is also common for the shortcut properties to have the command line listed.)
2) In a "pf" file. "PF" files are parameter files. They contain a list of parameters in a text file. This makes it easy to share and manage parameters between many scripts. To use a parameter file you need at least one -pf filename.pf parameter. Unix example:
#!/bin/sh
DLC=/usr/dlc
export DLC
${DLC}/bin/_progres -db mydb -pf mypf.pf
Where "mypf.pf" might contain:
# mypf.pf
-p start.p
-noincwarn
There is a global .pf file in the Progress install directory called startup.pf. You could also add it to that.
3) In an "ini file". Sort of like the pf file but more complicated. Indicated by the -ininame startup parameter. Can also be influenced by registry keys.
Why not removing or trying another value for -mmax? If you're moving from an old version of Progress it might be that -mmax is set very low.
The Maximum Memory (-mmax) client session parameter specifies the maximum amount of memory allocated for r-code segments, in kilobytes.
Source: http://knowledgebase.progress.com/articles/Article/P11351?popup=true
Large memory consumption might depend on complicated business logic (things like very large and or deeply nested procedures) so you might consider looking into that.
However a much easier fix would be to increase the value. Default is 3096, meaning each client "only" gets 3 Mb for this. Not a very large amount with today's standards.
If you really only want to suppress the message. Set -noincrwarn in your client side startup script (or corresponding .pf-file/startup.pf).
Hosting a WPF element (windows Presentation Foundation) in an OpenEdge application can cause application to crash if any message cover the window. It is also the case of this message.
In order to suppress any messages including message 5409 ()
According to article "HOW TO SUPPRESS WARNING MESSAGES (5407),(5408),(5409),(5410) FROM DISPLAYING ON CLIENT SCREENS."
I used with expected results SESSION:SUPPRESS-WARNINGS = YES. As the first line in the starting procedure of the aplication.
Using -noincrwarn as the session startup parameter had no effect in Open Edge 11.4
Supress openedge messages:
http://knowledgebase.progress.com/articles/Article/P79795?popup=true
.NET related error for OpenEdge-WPF hibrid application "Invisible or disabled control cannot be activated"
https://social.msdn.microsoft.com/Forums/windows/en-US/e8cf6431-2a59-4335-8b36-fc8f35083823/invisible-or-disabled-control-cannot-be-activated?forum=winforms
I'm running into problems when I turn my (working) java into an executable jar file.
I have a very simple number sorting program written. It's spread across two files (TreeGui.java and SortTree.java) that each do more or less what they say. TreeGui has an input textarea, a button and an output area. Pressing the button passes the input text to SortTree, which returns nicely sorted numbers that appear in the output box.
When I compile each file, and then run TreeGui, everything works fine
javac TreeGui.java
javac SortTree.java
java TreeGui
...runs everything lovely.
Now, when I try and put those classes into a jar file I keep bumping into the same string of problems. I have a manifest (TreeGuiManifest.txt) with the following (and a blank new line):
Main-Class: TreeGui
but when I put the whole lot together:
jar cmf TreeGuiManifest.txt TreeGui.jar TreeGui.class SortTree.class
I hit problems. Whether I run it directly by selecting the jar file or by using "java -jar TreeGui.jar" in the console, the program will load fine but the moment the button is pressed it throws a whole string that start like this and carry on for a long way:
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: SortTree TreeNode
at SortTree.treeInsert(SortTree.java:35)
at SortTree.main(SortTree.java:24)
at TreeGui.actionPerformed(TreeGui.java:66)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
etc. etc.
It's clearly struggling to find elements in the SortTree code that pressing the button in TreeGui demands but I'm not sure what I can do to make it work.
Am I missing something really obvious? I'm using a variety of imported java.utils.*; etc, do I have to mention them when I make my jar file? Thanks for any help.
(The only reason I haven't pasted the actual code of the programmes here is that it all works perfectly when it's not a Jar file... I'll happily add them if necessary though)
I'm trying out Specflow for the first time, and have created a VS2010 project with a reference to TechTalk.SpecFlow, as well as nunit.framework. I've added a sample Feature file:
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
#mytag
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen
When I execuyte the test (using TestDriven.Net), I get the following error:
Test 'T:SpecFlowFeature1' failed: Couldn't find type with name 'SpecFlowFeature1'
System.Exception: Couldn't find type with name 'SpecFlowFeature1'
at MutantDesign.Xml.Documentation.MemberInfoUtilities.FindMemberInfo(Assembly assembly, String cref)
at TestDriven.TestRunner.AdaptorTestRunner.Run(ITestListener testListener, ITraceListener traceListener, String assemblyPath, String testPath)
at TestDriven.TestRunner.ThreadTestRunner.Runner.Run()
Anyone know what I'm missing?
Actually traced this down to how I was running the test. Right clicking the ".feature" file (or anywhere within that file) and selecting "Run Tests" resulted in the error. Right clicking the underlying ".feature.cs" file and selecting "Run Tests" executed correctly. Looks like TestDriven.Net wasn't able to "understand" the "*.feature" file.
I typically start "Couldn't find type..." errors in my references folder and make sure that the library that I'm referencing is being referenced correctly and that the version that's being referenced isn't outdated.
Also, make sure that your SpecFlowFeature1 class isn't mistakenly declared as private. Visual Studio creates new classes (by default) as private and if you don't specify a class as public, it will remain private and not "visible" to outside projects.