In a screen function
In a ls call with "Ls Type: = 'L'
the characteristic LS Mode and DEF Mode are set to 'L'
in the FILESPEC'S for the file all modes are set to 'D'
if you umsg @MODE on the return no error it returns 'L' when infact it is deleting records ..
does anyone know another system variable I could call on to idenitfy the true mode it's in .. in this case delete.
Click the link below to see the new game I'm developing!
Returning Mode
Started by
Guest_Guest7_*
, Sep 01 2005 08:32 PM
7 replies to this topic
#2
CSuarezdelReal
-
- Members
-
- 91 posts
Advanced
- Gender:Not Telling
Posted 01 September 2005 - 10:25 PM
As you stated, @MODE returns a value of the running function, not the files themselves. A function could have a bunch of files in a variety of modes which could change based on the valid modes you defined for the function and how the user (or the app itself) select them.
Incidentally, you hard coded that when the mode of your function is "L" the file records will be deleted; which might sounds bizarre, but is a valid approach.
If you are using a single file, you can "synchronize" the file modes to the function modes, so that when function is in "D" mode the records of the file would be deleted. That way the @MODE call would return a more meaningful result for your sake. I do not know of any way to get the mode of the file, but if it is hard coded you could know that in advance, mapping the function mode to the desired file mode.
Incidentally, you hard coded that when the mode of your function is "L" the file records will be deleted; which might sounds bizarre, but is a valid approach.
If you are using a single file, you can "synchronize" the file modes to the function modes, so that when function is in "D" mode the records of the file would be deleted. That way the @MODE call would return a more meaningful result for your sake. I do not know of any way to get the mode of the file, but if it is hard coded you could know that in advance, mapping the function mode to the desired file mode.
Claudio Suarez del Real "It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change."
#3
Chris Pepper
-
- Members
-
- 369 posts
ProIV Guru
- Gender:Male
- Location:United Kingdom
Posted 02 September 2005 - 07:02 AM
Not sure why you would do that?
A screen mode of D works just like a Screen mode of L (except on a one time screen when you get a default Are You Sure? prompt which can be turned off - see recent post).
So the only other difference is showing "DELETE" on the screen rather than LOOKUP!
A screen mode of D works just like a Screen mode of L (except on a one time screen when you get a default Are You Sure? prompt which can be turned off - see recent post).
So the only other difference is showing "DELETE" on the screen rather than LOOKUP!
#5
Chris Pepper
-
- Members
-
- 369 posts
ProIV Guru
- Gender:Male
- Location:United Kingdom
Posted 02 September 2005 - 05:18 PM
In any screen you could be doing any combination of modes of action to any number of files.
The problem in ProIV is actually terminology - it uses the word Mode for two different things: screen modes and file modes.
If it is an LS Update the screen mode actually isn't relevant (as it's not really a screen). So you can set this to anything.
@MODE is only relevant if the screen mode can be changed by a user. I'm not sure what relevance an @MODE ceck would be in an LSUPDATE!
The problem in ProIV is actually terminology - it uses the word Mode for two different things: screen modes and file modes.
If it is an LS Update the screen mode actually isn't relevant (as it's not really a screen). So you can set this to anything.
@MODE is only relevant if the screen mode can be changed by a user. I'm not sure what relevance an @MODE ceck would be in an LSUPDATE!
#7
Chris Pepper
-
- Members
-
- 369 posts
ProIV Guru
- Gender:Male
- Location:United Kingdom
Posted 03 September 2005 - 07:02 AM
But if it's an LSUPDATE then each possible file access is only going to be in one mode like on a Global Update (even if there are multiple writes to the same file def).
So either you have a separate Logic on each, or if you are trying to save logic by combining them then you can use @CURRFL (check spelling!) to return the file number (is that what you mean)?
E.g.
01 FILE01 L L L L
02 FILE02 C C C C
03 FILE01 D D D D
So if you want the same logic on each file you can code CASE @CURRFL (sure that spelling is wrong!!) to take action if it's 1 (ie Look access), 2 (change), 3 (Delete).
(Sorry if I'm sounding grumpy! I'm off for a week now so should be chilled out again on my return!)
So either you have a separate Logic on each, or if you are trying to save logic by combining them then you can use @CURRFL (check spelling!) to return the file number (is that what you mean)?
E.g.
01 FILE01 L L L L
02 FILE02 C C C C
03 FILE01 D D D D
So if you want the same logic on each file you can code CASE @CURRFL (sure that spelling is wrong!!) to take action if it's 1 (ie Look access), 2 (change), 3 (Delete).
(Sorry if I'm sounding grumpy! I'm off for a week now so should be chilled out again on my return!)
Edited by Chris Pepper, 03 September 2005 - 07:03 AM.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
Click the link below to see the new game I'm developing!
