I'm having a problem running my script. I can't for the life of me figure out what the illegal character is.
I have tried putting the string concatenation on separate lines, and I get the same error. I have tried using OneDate and TwoDate instead of Date_1 and Date_2, also to no avail. I have updated AHK, which didn't solve it.
I should note that I am using both MonthCal and DateTime Gui control to get these dates, then formatting them with FormatTime. Another error I have noticed, which may provide a clue, is that no matter what dates I pick in the date controls, I get 2017-Sep-01 as the output. It's possible that no values are coming through from the controls, and the FormatTime function is using today's date because the variables it's attempting to work on are blank / don't exist.
Other than than, generally I like to be more descriptive in my questions, but in this case, I think all I can say is: "Help?"
When you use the expression assignment method := you shouldn't use %. Instead you should write Output := Output Date_1 "_to_" Date_2. When you do use % with expression assignment Autohotkey dereferences the variable and tries to treat OtherDescription--2017... as a variable name and - is not a legal character for an Autohotkey variable.
The following example will help make it more clear:
astring := "some text"
output = a
Output := %Output%STRING
MsgBox % Output
The MsgBox will show "some text". This happens because Autohotkey dereferences %Output% to "a" and then assigns to it the value of astring variable (it concatenates "a" and "STRING" and then looks for a variable called astring).
Related
I'm new to SAS and I'm trying to understand a code:
if MAP_ID="+" then output WORK.0201_template;
else
do;
SHEET_ID=MAP_ID;
output WORK.0201_template_f;
end;
What does it mean the MAP_ID="+"? Does it mean that it search on the table for the values where MAP_ID=+, or does it have another menaing?
Thanks
The MAP_ID="+" is a boolean expression that compares the value the variable MAP_ID to the character string literal "+". It will be true when they are the same and false otherwise.
I suspect that the main purpose of this code is to split the data into two different output datasets based on the value of MAP_ID.
It also is changing the value of SHEET_ID. That type of code also looks like something that is designed to carry forward the value of MAP_ID in a retained field SHEET_ID. If I am right then the meaning of the value of + is to keep the same sheet_id. But we would need to seem more of the code and the data to really tell.
I have been working with Excel for a while, yet i have never read what is the difference between these two operators ("regardless of i have used both")
:= and = in Excel VBA
As you already know, = is used to assign values or set objects - e.g. i=1
:= on the other hand (like Comintern mentioned), is used to to assign a value to a certain named argument, afaik only ever inside a method or function.
Consider the following example: you could use something like MsgBox "Hello World", , "Title1" - specifying MsgBox's arguments in the default order - the prompt, the default Buttons-style, then the Title.
Alternatively, one could use := to write MsgBox Title:="Title1", prompt:="Hello world"
Notice that
the order of the arguments is of no importance here and
there is no need to specify empty placeholders for default-arguments , ,.
Let us take for example the Range.Find method
expression.Find(What, After, LookIn, LookAt, SearchOrder, SearchDirection, MatchCase, MatchByte, SearchFormat)
That is a LOT of conditions to set! But you just want a simple search of the number 2 in Range("A1:A500"):
Without the := operator, you would have to use commas to get to any optional variables to set:
Range("A1:A500").Find(2, , xlValue, , , , , , )
With the := operator, you can specify which conditions you want without delineating through all the default settings:
Range("A1:A500").Find(what:=2, lookin:=xlValues)
I'm pretty new to progress and I want to ask a question.
How do I change variable (string) length in runtime?
ex.
define variable cname as char.
define variable clen as int.
cname= "".
DO cnts = 1 TO 5.
IF prc[cnts] <> "" THEN DO:
clen = clen + LENGTH(prc[cnts]).
cname = cname + prc[cnts].
END.
END.
Put cname format '???' at 1. /here change variable length/
Thanks for the reply
If the PUT statement is what you want to change, then
PUT UNFORMATTED cname.
will write the entire string out without having to worry about the length of the FORMAT phrase.
If you need something formatted, then
PUT UNFORMATTED STRING(cname, fill("X", clen)).
will do what you want. Look up the "STRING()" function in the ABL Ref docs.
In Progress 4GL all data is variable length.
This is one of the big differences between Progress and lots of other development environments. (And in my opinion a big advantage.)
Each datatype has a default format, which you can override, but that is only for display purposes.
Display format has no bearing on storage.
You can declare a field with a display format of 3 characters:
define variable x as character no-undo format "x(3)".
And then stuff 60 characters into the field. Progress will not complain.
x = "123456789012345678901234567890123456789012345678901234567890".
It is extremely common for 4gl application code to over-stuff variables and fields.
(If you then use SQL-92 to access the data you will hear much whining and gnashing of teeth from your SQL client. This is easily fixable with the "dbtool" utility.)
You change the display format when you define something:
define variable x as character no-undo format "x(30)".
or when you use it:
put x format "x(15)".
or
display x format "x(43)".
(And in many other ways -- these are just a couple of easy examples.)
Regardless of the display format the length() function will report the actual length of the data.
Is there any way of programmatically getting the value of a Text Symbol at runtime?
The scenario is that I have a simple report that calls a function module. I receive an exported parameter in variable LV_MSG of type CHAR1. This indicates a certain status message created in the program, for instance F (Fail), X (Match) or E (Error). I currently use a CASE statement to switch on LV_MSG and fill another variable with a short description of the message. These descriptions are maintained as text symbols that I retrieve at compile time with text-MS# where # is the same as the possible returns of LV_MSG, for instance text-MSX has the value "Exact Match Found".
Now it seems to me that the entire CASE statement is unnecessary as I could just assign to my description variable the value of the text symbol with ID 'MS' + LV_MSG (pseudocode, would use CONCATENATE). Now my issue is how I can find a text symbol based on the String representation of its ID at runtime. Is this even possible?
If it is, my code would look cleaner and I wouldn't have to update my actual code when new messages are added in the function module, as I would simply have to add a new text symbol. But would this approach be any faster or would it in fact degrade the report's performance?
Personally, I would probably define a domain and use the fixed values of the domain to represent the values. This way, you would even get around the string concatenation. You can use the function module DD_DOMVALUE_TEXT_GET to easily access the language-dependent text of a domain value.
To access the text elements of a program, use a function module like READ_TEXT_ELEMENTS.
Be aware that generic programming like this will definitely slow down your program. Whether it would make your code look cleaner is in the eye of the beholder - if the values change rarely, I don't see why a simple CASE statement should be inferior to some generic text access.
Hope I understand you correctly but here goes. This is possible with a little trickery, all the text symbols in a report are defined as variables in the program (with the name text-abc where abc is the text ID). So you can use the following:
data: lt_all_text type standard table of textpool with default key,
lsr_text type ref to textpool.
"Load texts - you will only want to do this once
read textpool sy-repid into lt_all_text language sy-langu.
sort lt_all_Text by entry.
"Find a text, the field KEY is the text ID without TEXT-
read table lt_all_text with key entry = i_wanted_text
reference into lsr_text binary search.
If you want the address you can add:
field-symbols: <l_text> type any.
data l_name type string.
data lr_address type ref to data.
concatenate 'TEXT-' lsr_text->key into l_name.
assign (l_name) to <l_text>.
if sy-subrc = 0.
get reference of <l_text> into lr_address.
endif.
As vwegert pointed out this is probably not the best solution, for error handling rather use message classes or exception objects. This is useful in other cases though so now you know how.
So I'm a complete fledgling when it comes to Smalltalk and right now I'm writing a very simple app with a GUI. All this app does is add two operands together from two input fields and displays the sum in a third, read-only input field.
I am having trouble with VisualWorks recognizing temporary variables that I have already declared.
I try to highlight any line with a declared temporary variable, and it will say such variable has not been declared; do I want to declare it as temp, instance, shared, etc... It's especially strange because the method can be accepted and even read through when I run it by the GUI,(although I am having a problem typecasting the variables as integers) but if I want to print or inspect any line with a declared temporary variable, it will say that it doesn't recognize it as such and do I want to declare it as this or that.
The Code:
add
"adds two input fields"
| op1 op2 result |
op1 := #InputOperand1 value asInteger.
op2 := #InputOperand2 value asInteger.
result := op1 + op2.
^result
Any ideas?
The problem is that only the text you've selected is compiled and evaluated. If you are only selecting a single line, then the variable declarations aren't included in the compiled code. If you select the whole method body for evaluation (not including the method signature), it should work fine. Another option is to just choose "create temp" when the compiler prompts, and then revert to the saved version of the method to get rid of the extra temp declaration.