How to conditionally prevent an include file from being executed with Progress ABL? - openedge

To those who know,
How does one conditionally prevent an include from being executed in Progress ABL? Is that even possible? If not what do you purpose?
Based on user selection - here is an example:
If checkBox = yes then
{randomInclude.i}
Else
"Do remaining things"

You might need to share the code of your include file to make your request clearer to us.
TheDrooper's answer shows how to do it based on a compile time condition. Your sample seems to be based on a runtime solution. In that case I'd do:
If checkBox = yes then do:
{randomInclude.i}
end.
Else do:
"Do remaining things"
end.
The do-block is required as you just don't know how many statement are inside the include file.

When you define an include file in your program, the contents of the include are placed in your program at that position. In your example, whatever is in randominclude.i is stuck in the "then" condition. As Tom said, you probably just need to wrap it in a DO-END block. You can also put that in the include file.
You can also conditionally include a file at compile time. Suppose this is the contents of randominclude.i:
MESSAGE "Included" VIEW-AS ALERT-BOX INFORMATION.
You can define a preprocessor in your program to add the include:
&SCOPED-DEFINE UseIt
&IF DEFINED(UseIt) &THEN
{randominclude.i}
&ENDIF
Run that and you'll get an "Included" pop-up message. But change the preprocessor to this:
&SCOPED-DEFINE DontUseIt
Run the program now and nothing will happen because "UseIt" is no longer defined so randominclude.i is not included in the program.

Related

Control-M How do I remove a portion of the filename during Advanced File Transfer

I am trying to figure out how I can simply remove a portion of a filename on a transfer. I need the numbers to remain unchanged with 'check-aft' buttressing up against them as a prefix.
Source: check-aft-eft-12345678-0001
Destination: check-aft12345678-0001
I cannot for the life of me figure out how to either use the Find and Replace feature which BMC mentions, but then provides zero guidance for, or how I would utilize the variables to do so. I have review all of their documentation and watched so many videos, but they do not cover this scenario.
I would appreciate any help getting '-eft-' removed from this filename.
I have tried creating variables for '-eft-' and for 'check-aft' but I am unable to figure out how i can tell it to look for 'check-aft-eft-' and remove '-eft-'
Find & Replace is used for making bulk changes to job definitions, it has no direct relation to AFT jobs (unless you are changing the AFT job defs, that is).
The AFT jobs have many useful features hidden away on the "Advanced" button. If you literally want to change the file name, click Advanced and go to "Destination Actions" on the General tab. Here select "Renamed" where it says "After the completion of a successful file transfer the destination file will be:" and enter check-aft12345678-0001.
If, however, the numbers can be any value - go to the "File Watcher" tab (still in the "Advanced" pop-up) and use "Output / Variable containing detected file name". Set it to something like found_aft_file_1.
You now have a variable that you can do SUBSTR on -
%%PARTONE = %%SUBSTR %%found_aft_file_1 1 10
%%PARTTWO = %%SUBSTR %%found_aft_file_1 15 13
Then %%PARTONE.%%PARTTWO will return the required value.

How to view decompiled R code in order to debug it?

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

Is it possible to show all options in Tokenize2?

Tokenize2 is a javacsript lib to select multiple options.
It provides a very neat UI to start writing and then get a list of options to select from. Selected options will show up as "tags" that can be removed with "x" link.
So far all is fine. But Right now you need to know what your looking for and start write at least one character to see matching alternatives.
In my scenario there are very few alternatives and they are not known to the user. I would like to show ALL options when the user clicks the input box. There is a configuration option named searchMinLength but it is already set to 0.
Is there a workaround that can be used? Maybe like triggering load and dropdown manually?
I know there are a lot of similar alternatives but I picked Tokenize2 because:
It looks clean and nice
It works in mobile browsers
I don't know if there is an "official" approach, but after some investigation I have found an acceptable workaround.
After downloading the Tokenizer2 sourceode I found the following line that triggered my attention:
if(this.input.val().length > 0){
this.trigger('tokenize:search', [this.input.val()]);
}
My interpretation is that the internal search command is not triggered unless the user input has at least one character. This line in sourcecode could easily be modified. I have filed a suggestion for this here: https://github.com/zellerda/Tokenize2/issues/26
My current workaround is to add an event listener for the select event and there trigger the internal search command. That works fine for my scenario and does not force a source code rewrite.
$("#my-dropdown").on("tokenize:select", function (e: Event, routedEvent: boolean) {
$("#my-dropdown").trigger('tokenize:search', "");
});
Tokenize2
This link worked for me GitHub
$('.tokenize-sample-demo1').on('tokenize:select', function(container){
$(this).tokenize2().trigger('tokenize:search', [$(this).tokenize2().input.val()]);
});

Refactor Massive Cucumber Step Definition

My team is currently taking our old UI acceptance test scripts and automating them. To do this we are using Jruby, Cucumber and Watir-Webdriver. So far the automation process has been going pretty well. The only problem we have is that our step definitions are starting to get a bit out of hand.
For example, in most of our scenarios is a section like this:
Given I press the SEARCH_BUTTON
Then I should land on the SEARCH_PAGE
and the step definitions look like this:
Given(/I press the (.*)$/) do |buttonName|
if buttonName == 'SEARCH_BUTTON'
eval "$browser.#{$DataHash['home']['searchButton']}.when_present.click"
elsif buttonName == 'LOGIN_BUTTON'
eval "$b.#{$DataHash['loginPage']['loginButton']}.click"
elsif buttonName == 'HOME_BUTTON'
eval "$b.#{$DataHash['mainPage']['HomeButton']}.click"
elsif buttonName == 'ADD_PRODUCT_BUTTON'
#This if else ladder goes on like this for another 300+ lines
...
end
end
The $DataHash variable refers to config.yml, which uses a hash to store all of the different web elements we are using.
config.yml
home:
searchButton: "link(:id => 'searchBtn')"
searchTypeSelectBox: "select_list(:name => 'matchType')"
searchResetButton: "button(:id => 'resetSearch')"
#rest of the elements on the home page...
loginPage:
loginButton: "link(:id => 'login')"
#rest of the elements on the login page...
....
So $browser.$DataHash['home']['searchButton'].when_present.click is equivalent to $browser.link(:id => 'searchBtn').when_present.click
We are using this basic step definition for every button that a user could click, and at this point this one step definition is something like 300+ lines of code. Most of which are single lines like above. Our other step definitions have the same sort of problem. Are there any good ways of refactoring our step definitions to make them less bloated, or at least easier to search through, without making the actual steps any less re-useable?
Initially we thought we could have the same step definition in multiple files based on which page was being tested. So in searchDefinitions.rb there would be a step definition for Given(/I press the (.*)$/) do |buttonName| which only had the different buttons found on the search page. Then in homeDefinitions.rb would be the same step definition but only with code for the home page buttons. Basically breaking up the if-else ladder across multiple files. Of course, Cucumber doesn't allow the same step definition in multiple files so now we're at a bit of a loss.
As you mentioned you can reuse steps see Reuse Cucumber steps. But I personally found it pretty complicated when I tried to do it. So, from my side I suggest you to implement Page Object pattern. The idea is that you describe your pages or even some modules like separate entities which provides you with ability to interact with them. For understanding concept see here. And here you can find some example. Assuming this your step definition would like
Given(/I press the (.*)$/) do |buttonName|
#my_home_page.click_search_button
...
end
end
Where click_search_button method encapsulates your 'ladder' logic to press login button if search button is not present yet.
Hopefully it makes sense for you.
Supposing that the minor differences in the eval lines you show don't matter, extract the hash values that vary into a constant
BUTTON_KEYS = {
'search' => %w(home searchButton),
'login' => %w(loginPage loginButton)
# ...
}
and use it in your step definition:
Given(/I press the (.*) button$/) do |button_name|
keys = BUTTON_KEYS['button_name']
eval "$browser.#{$DataHash['#{keys[0]}']['#{keys[1]}']}.when_present.click"
end
Now you have half as many lines of code and less duplication.
I changed the step regexp to include "button", to remove that duplication from the button names, and the button names to be lowercase, as in normal English. Whether or not you're showing your feature files to non-programmers, Cucumber step names should read like natural language so that you can think about product requirements and not implementation details when you're reading them.
Alternative suggestion, valid if the two levels of keys in the the YAML are not really needed:
You could restructure the YAML like so
search button: "link(:id => 'searchBtn')"
search type select box: "select_list(:name => 'matchType')"
search reset button: "button(:id => 'resetSearch')"
# rest of the elements on the home page...
login button: "link(:id => 'login')"
# rest of the elements on the login page...
# ...
Then you wouldn't need the hash at all, and your step could just be
Given(/I press the (.*)$/) do |element_name|
eval "$browser.#{$DataHash['#{element_name}']}.when_present.click"
end
Or you could convert the YAML entirely into a hash (representing the method as a string and calling it with .send), which would prevent you from making some syntax errors.

how to use QTable::editCell()

I don't understand how QTable::editCell() should be used. I am trying to do some error checking based on entries made by user in a QTable as mentioned in my another question.
I would like to give user an opportunity to re-edit the cell which has error. For example, if name column entry has some special characters such as '(', the user should be prompted for the error and the control should go back to same cell in edit mode. I tried using QTable::editCell() in my code as shown below.
Table->editCell(row, 0, TRUE);
name = Table->text(row, 0);
However, this doesn't work as expected. The control doesn't stay in the cell at all and obviously the name is not correctly collected. So, my question is how to ensure from within code that a cell of QTable can be edited so that the edited contents can be accessed immediately in next statement (as shown in above code).
Note: I am working with qt 3.3.8 only.
I don't think you can do that. You'll have to go back to the event loop, and wait for one of the signals (like valueChanged(row,col)) to be fired to re-validate the data.
A blocking wait on a GUI object is often not a good approach (except for modal dialogs).
I know I'm a little late here but you should use the following connect statement with your own custom function to do your specific needs such as below. You can also use this method to disable users from entering in special characters within you custom function. That way they wont ever have to correct undesirable characters.
connect(ui->tableWidget, SIGNAL(cellChanged(int,int)), this, SLOT(customFunction(int,int)));
void updateTable
{
//remove invalid characters
}

Resources