1 for certain symbols like (/), (,) and (;) while taking input.
2. Timeout error while taking input
3. very big floating value as input
4. and for improper inputs like - 4/3
I found out how to time-out the program after a specific time:
https://gcc.gnu.org/onlinedocs/gcc-4.3.2/gfortran.pdf (find: alarm)
If I interpret your question correctly, you want to check user input for correct values and interpret lists and fractions. I'm assuming you mean from console, a la
read(*,*) character-variable
The other option is to use formatted input, for example
read(*,'(i4)') integer-variable
which would read an integer with four digits.
This method would possibly already remove some of your problems, because the user input has to match the specified format or the program reports a runtime error. It is possible to specify the number of input values as well (separated by whitespace, ',' or ';'). Hence if you know beforehand how many values you are getting, the user can enter lists. If you make the requirements clearer, it will be easier to help. Fortran is a bit finicky for I/O.
If you really need the input to be of a general not-defined-at-compile-time type, you'll have to parse the string. This is also true if you want the user to be able to enter fractions like '4/3'.
I'm not aware of a method to restrict the time which a user has to enter values. It may be possible, but I've never seen it.
For too big or improper values you just can, for example, wrap the read statement in an endless do loop and exit if the number(s) is/are correct
do
read(*,'(i6)') x
if ( (x.lt.1e5).and.(x.ge.0) ) exit
end do
This would request an integer x from the user until the input is smaller than 100 000 and at least 0.
edit after discussion in comments:
The following code may be what you want:
implicit none
integer :: x
character(len=10) :: y
y=''
print*,'Enter one integer:'
do
read(*,'(i10,a)') x,y
if( (y.eq.'').and.(x.lt.1e5) ) exit
print*,'Enter one valid integer, smaller than 100 000, only:'
end do
print*,x
end
It just reads until there is exactly one integer smaller than 100 000 in the input. If you want a better user experience you can catch 'very' invalid input (that the program complains about and stops) with the iostat parameter.
One thing though: on my two available compilers (GCC 4.4.7 and Intel fortran compiler 11.0) the forward slash '/' is not a valid integer input and the program stops. If that is different for your compiler the code above should still work, but I can't test that.
Related
I am working on some legacy code at the moment and have come across the following:
FooString = String.Format("{0:####0.000000}", FooDouble)
My question is, is the format string here, ####0.000000 any different from simply 0.000000?
I'm trying to generalize the return type of the function that sets FooDouble and so checking to make sure I don't break existing functionality hence trying to work out what the # add to it here.
I've run a couple tests in a toy program and couldn't see how the result was any different but maybe there's something I'm missing?
From MSDN
The "#" custom format specifier serves as a digit-placeholder symbol.
If the value that is being formatted has a digit in the position where
the "#" symbol appears in the format string, that digit is copied to
the result string. Otherwise, nothing is stored in that position in
the result string.
Note that this specifier never displays a zero that
is not a significant digit, even if zero is the only digit in the
string. It will display zero only if it is a significant digit in the
number that is being displayed.
Because you use one 0 before decimal separator 0.0 - both formats should return same result.
I'm trying to write a function of this form:
Function cont(requestdate As Date)
cont = requestdate
End Function
Unfortunately, when I enter =cont(12/12/2012) into a cell, I do not get my date back. I get a very small number, which I think equals 12 divided by 12 divided by 2012. How can I get this to give me back the date? I do not want the user to have to enter =cont("12/12/2012").
I've attempted to google for an answer, unfortunately, I have not found anything helpful. Please let me know if my vocabulary is correct.
Let's say my user pulled a report with 3 columns, a, b and c. a has beginning of quarter balances, b has end of quarter balances and c has a first and last name. I want my user to put in column d: =cont(a1,b1,c1,12/12/2012) and make it create something like:
BOQ IS 1200, EOQ IS 1300, NAME IS EDDARD STARK, DATE IS 12/12/2012
So we could load this into a database. I apologize for the lack of info the first time around. To be honest, this function wouldn't save me a ton of time. I'm just trying to learn VBA, and thought this would be a good exercise... Then I got stuck.
Hard to tell what you are really trying to accomplish.
Function cont(requestdate As String) As String
cont = Format(Replace(requestdate, ".", "/"), "'mm_dd_YYYY")
End Function
This code will take a string that Excel does not recognize as a number e.g. 12.12.12 and formats it (about the only useful thing I can think of for this UDF) and return it as a string (that is not a number or date) to a cell that is formatted as text.
You can get as fancy as you like in processing the string entered and formatting the string returned - just that BOTH can never be a number or a date (or anything else Excel recognizes.)
There is no way to do exactly what you're trying to do. I will try to explain why.
You might think that because your function requires a Date argument, that this somehow forces or should force that 12/12/2012 to be treated as a Date. And it is treated as a Date — but only after it's evaluated (only if the evaluated expression cannot be interpreted as a Date, then you will get an error).
Why does Excel evaluate this before the function receives it?
Without requiring string qualifiers, how could the application possibly know what type of data you intended, or whether you intended for that to be evaluated? It could not possibly know, so there would be chaos.
Perhaps this is best illustrated by example. Using your function:
=Cont(1/1/0000) should raise an error.
Or consider a very simple formula:
=1/2
Should this formula return .5 (double) or January 2 (date) or should it return "1/2" (string literal)? Ultimately, it has to do one of these, and do that one thing consistently, and the one thing that Excel will do in this case is to evaluate the expression.
TL;DR
Your problem is that unqualified expression will be evaluated before being passed, and this is done to avoid confusion or ambiguity (per examples).
Here is my method for allowing quick date entry into a User Defined Function without wrapping the date in quotes:
Function cont(requestdate As Double) As Date
cont = CDate((Mid(Application.Caller.Formula, 7, 10)))
End Function
The UDF call lines up with the OP's initial request:
=cont(12/12/2012)
I believe that this method would adapt just fine for the OP's more complex ask, but suggest moving the date to the beginning of the call:
=cont(12/12/2012,a1,b1,c1)
I fully expect that this method can be optimized for both speed and flexibility. Working on a project now that might require me to further dig into the speed piece, but it suits my needs in the meantime. Will update if anything useful turns up.
Brief Explanation
Application.Caller returns a Range containing the cell that called the UDF. (See Caveat #2)
Mid returns part of a string (the formula from the range that called the UDF in this case) starting at the specified character count (7) of the specified length (10).
CDate may not actually be necessary, but forces the value into date format if possible.
Caveats
This does require use of the full dd/mm/yyyy (1/1/2012 would fail) but pleasantly still works with my preferred yyyy/mm/dd format as well as covering some other delimiters. dd-mm-yyyy or dd+mm+yyyy would work, but dd.mm.yyyy will not because excel does not recognize it as a valid number.
Additional work would be necessary for this to function as part of a multi-cell array formula because Application.Caller returns a range containing all of the associated cells in that case.
There is no error handling, and =cont(123) or =cont(derp) (basically anything not dd/mm/yyy) will naturally fail.
Disclaimers
A quick note to the folks who are questioning the wisdom of a UDF here: I've got a big grid of items and their associated tasks. With no arguments, my UDF calculates due dates based on a number of item and task parameters. When the optional date is included, the UDF returns a delta between the actual date and what was calculated. I use this delta to monitor and calibrate my calculated due dates.
All of this can absolutely be performed without the UDF, but bulk entry would be considerably more challenging to say the least.
Removing the need for quotes sets my data entry up such that loading =cont( into the clipboard allows my left hand to F2/ctrl-v/tab while my right hand furiously enters dates on the numpad without need to frequently (and awkwardly) shift left-hand position for a shift+'.
As I understood, select-options in abap just takes 45 characters from UI.
Whatever I assign the type of select-option, it doesnt take more then 45 characters.
SELECT-OPTIONS: s_key FOR somlreci1-receiver NO INTERVALS VISIBLE LENGTH 100.
somlreci1-receiver is char(1215). But I cannot write more than 45 into that select-option.
Any way to increase this length ?
This official link
http://help.sap.com/abapdocu_70/en/ABAPSELECT-OPTIONS.htm
says it isn't possible to pass input larger than 45 chars, sorry :|
At the end of the documentation posted by #vlad-ardelean it mentions that:
If a selection criterion for data types is supplied with data when
calling up an executable program with SUBMIT
...
If the selection criterion is declared with the addition NO-DISPLAY,
no conversion routine or truncation will be performed for the first
row either.
You could declare the select-options as NO-DISPLAY in your main program, then call it from a second program with
SUBMIT programname WITH so_field EQ lv_longdata SIGN 'I'.
...or similar to pass the long value to the main program. It's a pretty convoluted way of doing it, however.
In addition to #vlad-ardelean's answer: It might be interesting to note that in recent releases, the maximum field length was raised to 255 characters (see http://help.sap.com/abapdocu_731/en/ABAPSELECT-OPTIONS.htm).
Why does Microsoft tend to report "error codes" as hexadecimal values?
Error codes are 32-bit double word values (4 byte values.) This is likely the raw integer return code of whatever C-style function has reported an error.
However, why report the error to a user in hexadecimal? The "0x" prefix is worthless, and the savings in character length is minimal. These errors end up displayed to end users in Microsoft software and even on Microsoft websites.
For example:
0x80302010 is 10 characters long, and very cryptic.
2150637584 is the decimal equivalent, and much more user friendly.
Is there any description of the "standard" use of a 32-bit field as an error code mechanism (possibly dividing the field into multiple fields for developer interpretation) or of the logic behind presenting a hexadecimal code to end users?
We can only guess about the reason, so this question cannot be answered for sure. But let's guess:
One reason might be that with hex numbers, you know the number will have 8 digits. If it has more or less digits the number is "corrupt" (for example, the customer mistyped). With decimal numbers the number of digits for the same value varies.
Also, to a developer, hex numbers are more convenient and natural than decimal numbers. For example, if some info is coded as bit flags you can decipher them manually easily in hex numbers but not in decimal numbers.
It is a little bit subjective as to whether hexadecimal or decimal error codes are more user friendly. Here is a scenario where the hexadecimal error codes are significantly more convenient, which could be part of the reason that hexadecimal error codes are used in the first place.
Consider the documentation for Win32 Error Codes for Active Directory Service Interfaces, ADSI uses error codes with the format 0x8007XXXX, where the XXXX corresponds to a DWORD value that maps to a Win32 error code.
This makes it extremely easy to get the corresponding Win32 error code, because you can just strip off the last 4 digits. This would not be possible with a decimal error code representation.
The middle ground answer to this would be that formatting the number like an IPv4 address would be more luser-friendly while preserving some sort of formatting that helps the dev guys.
Although TBH I think hex is fine, the hypothetical non-technical user has no more idea what 0x1234ABCD means than 1234101112 or "Cracked gangle pin on fwip valve".
For example:
code = '7777-5';
input = code.substring(0, 4); // Returns '7777'
checkdigit = f(input); // f() produces a checkdigit
assert.areEqual(code, input + "-" + checkdigit)
Is there a technical term for input used above?
Specifically I'm calculating checkdigits for ISBNs, but that shouldn't effect the answer.
Is "original number excluding the check digit" technical enough? :)
Actually, it's often the case, as in the link you posted, that the check digit or checksum ensures a property about the full input:
...[the check digit] must be such that the sum of all the ten digits, each multiplied by the integer weight, descending from 10 to 1, is a multiple of the number 11.
Thus, you'd check the full number and see if it meets this property.
It's "backwards" when you're initially generating the check digit. In that case, the function would be named generate_check_digit or similar, and I'd just name its parameter as "input".
Although I am not sure if there is a well-known specific technical term for the input, what LukeH suggested (message/data) seems common enough.
Wiki for checksum:
With this checksum, any transmission error that flips a single bit of the message, or an odd number of bits, will be detected as an incorrect checksum
Wiki for check digit:
A check digit is a form of redundancy check used for error detection, the decimal equivalent of a binary checksum. It consists of a single digit computed from the other digits in the message.