Author |
Topic: COMLIB failing parameter passing to FN_getvaluestr (Read 1036 times) |
|
Edja
New Member
member is offline
Posts: 22
|
 |
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #4 on: Apr 25th, 2017, 9:57pm » |
|
Richard,
Yes, your line
Code:A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells("+STR$(M%)+","+STR$(N%)+").value")
But then, why is it that the line (with the global variables I% and J%)
Code:A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells(I%,J%).value")
Quote:| Note that in any case the passing of named variables is not compatible with compiling the program with the Abbreviate names crunch option, unless you use the REM!Keep compiler directive. It may therefore be better to convert the variables' values to strings using STR$ |
|
This hints towards the way you've coded the line, but since I was not compiling, this shouldn't apply in this case. Is this then a general rule or am I still missing the point ? My real program contains at least 50 instances of this type and it functions exemplary (with the exception discussed here)
I've modified my code as in your example.
Thank you!
Eddy
|
|
 Logged
|
|
|
|
Edja
New Member
member is offline
Posts: 22
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #5 on: Apr 25th, 2017, 10:22pm » |
|
And just out of curiosity I've just replaced the capital letter variables M% and N% by m% and n%
Code: DEFFNConvert(m%,n%) LOCAL A$,A% A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells(m%,n%).value") A%=FN_findreplace(A$,",",".",0) =VALA$
?
Eddy
|
|
Logged
|
|
|
|
hellomike
Junior Member
member is offline
Gender: 
Posts: 55
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #6 on: Apr 26th, 2017, 08:29am » |
|
Note also that in the FN_getvaluestr() definition in COMLIB, variables O%,L%,S%,R%,V% are used locally and more in functions that it needs, but not I% and J%. So I wouldn't be surprised that it will then substitute the wrong (local) values.
That would also explain why
Code:A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells(I%,J%).value")
and
Code:A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells("+STR$(M%)+","+STR$(N%)+").value")
and
Code:A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells(m%,n%).value")
Cheers
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #7 on: Apr 26th, 2017, 11:35am » |
|
on Apr 25th, 2017, 9:57pm, Edja wrote:| But then, why is it that the line (with the global variables I% and J%) also does work ? |
|
COMLIB tries to help you out by using EVAL to discover the value(s) of any variables passed (by name) in parameter strings, but obviously that can only work when the variable concerned still has that value at the point EVAL is used. This will not (generally) be the case for the static integer variables (A% to Z% inclusive), and some other short variable names, because they may well be used locally within COMLIB.
The reason I% and J% worked for you is a fluke: it must be the case, by chance, that neither of those variables is used within COMLIB as a LOCAL or PRIVATE variable, or as a formal parameter. There is no guarantee at all that your program would survive a change to COMLIB, because there is nothing 'contractual' about which variables it uses internally.
The other reason that passing variables by name will commonly fail is as a result of 'crunching', when the variable name(s) within your parameter string no longer correspond with the actual variable name(s) in the program.
So the general rule is that any variables passed within parameters in this way must be specified in a REM!Keep compiler directive. Consequently such variables must meet the naming rules for REM!Keep, i.e. they "must have at least three characters (excluding the type character, if any)". The static integer variables like I% and J% do not meet this condition.
Perhaps the description of the library should state this more explicitly, but (and this was several years ago) I probably assumed that it was 'obvious' that static integer variables should not be passed to COMLIB 'by name'.
Richard.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #8 on: Apr 26th, 2017, 11:45am » |
|
on Apr 26th, 2017, 08:29am, hellomike wrote:| variables O%,L%,S%,R%,V% are used locally and more in functions that it needs |
|
As I said in my reply to Edja, you should not pass any static integer variables (or indeed any variable that does not meet the conditions for REM!Keep) 'by name' in a COMLIB parameter string.
Personally I prefer not to rely on COMLIB evaluating named variables at all, but rather to substitute the actual numeric value within the parameter string, as my suggested modification did. This is what you always have to do with OSCLI commands and it makes debugging easier.
Richard.
|
|
Logged
|
|
|
|
Edja
New Member
member is offline
Posts: 22
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #9 on: Apr 26th, 2017, 1:28pm » |
|
Quote:| The reason I% and J% worked for you is a fluke .... |
|
After your first reply I've already modified my code in line with your example. But I didn't completely understand why this was necessary and why my line (with I% and J%) did work.
Now I do. Thank you for this detailed answer.
Eddy
|
|
Logged
|
|
|
|
Edja
New Member
member is offline
Posts: 22
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #10 on: May 14th, 2017, 4:40pm » |
|
A few weeks ago Malcolm has uploaded COMLIBZ, an adapted version of COMLIB. While at the time I had already sorted out (with your help) my problems, I did modify my existing program.
With COMLIBZ lines like
Code:A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells(M%,N%).value")
Code:A$=FN_getvaluestr(Xlbook%,"ActiveSheet.cells("+STR$(M%)+","+STR$(N%)+").value")
Also the variable prefixes B, G, ... are no longer required (at least when working with Excel, as in my case) or are to be preceded with a *, giving more freedom in the choice of variable names.
Adapting my program took me about 5 min and it now is definitely more readable and easier to debug. I admit that I didn't test all possible scenarios and I didn't compile anything.
Considering the quality of the since long time available and tested COMLIB, this adapted version COMLIBZ is perhaps not really a major leap forward but rather a convenient face lift of the existing library. Nice !
Eddy
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #11 on: May 14th, 2017, 5:06pm » |
|
on May 14th, 2017, 4:40pm, Edja wrote:| A few weeks ago Malcolm has uploaded COMLIBZ, an adapted version of COMLIB. |
|
It's the first I've heard of it, and a search for 'COMLIBZ' over a period of 777 days returns only your post! So I'm thoroughly puzzled. As far as I'm aware the only way to evaluate variables passed in a string is using EVAL, with all the attendant issues that raises.
Richard.
|
|
Logged
|
|
|
|
Edja
New Member
member is offline
Posts: 22
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #12 on: May 14th, 2017, 6:33pm » |
|
Richard,
here's the mail that Malcolm send out to announce the availibility of COMLIBZ. I just followed the link(s).
Eddy
Quote:
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #13 on: May 15th, 2017, 06:31am » |
|
on May 14th, 2017, 6:33pm, Edja wrote:| here's the mail that Malcolm send out to announce the availibility of COMLIBZ. I just followed the link(s). |
|
That seems to refer to the original 'bbcbasic' Yahoo! group (the pre-existing group that I temporarily 'adopted'), which was subsequently replaced by the 'bb4w' Yahoo group, which was in turn replaced by the 'groups.io' group! When you say that it was uploaded a few weeks ago, do you actually mean many years ago?
There are only three groups/forums currently used to support BB4W and BBCSDL: the Wiggio group (which is due to close down soon), the Groups.io group and this Conforums group. All other earlier groups are either inaccessible, closed or defunct.
Richard.
|
|
Logged
|
|
|
|
Edja
New Member
member is offline
Posts: 22
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #14 on: May 15th, 2017, 10:21am » |
|
Quote:| When you say that it was uploaded a few weeks ago, do you actually mean many years ago? |
|
The upload dates from 30 april 2017.
Quote:| There are only three groups/forums currently used to support BB4W and BBCSDL |
|
OK, but the Yahoo site is still accessible and as you can see Malcolm has succeeded to upload a file and sent a mail (to all members ?). I still have access to the Yahoo Group and could navigate around to find the file and download it.
I've just made a check. Since 2006 there have been no downloads.
Except : just recently since 30 april 2017 Malcolm has downloaded 4 .
Quote:Just follow the links. Maybe if you're not a member anymore, you may have to register first, I'm not sure.
Or, if you prefer, I can send you the files directly. Just let me know.
Quote:| There are only three groups/forums currently used to support BB4W and BBCSDL: the Wiggio group (which is due to close down soon), the Groups.io group and this Conforums group |
|
The general conclusion, I think, is that Malcolm just needs to be reminded to upload to one of the new groups (Groups.io or this Conforum)
It would be a waste to loose his, and possibly, though not likely, other people's contributions
Eddy
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: COMLIB failing parameter passing to FN_getvalu
« Reply #15 on: May 15th, 2017, 11:30am » |
|
on May 15th, 2017, 10:21am, Edja wrote:| the Yahoo site is still accessible |
|
Not to me, but I vaguely remember being banned from that group just after I created the 'bb4w' group as a replacement. My recollection is that somebody unhappy with BB4W and/or me somehow managed to contact the original group owner (who had been 'absent' for years) and persuaded him to take it over again. One of his actions was to set it so all messages require approval, and another was to ban me. If you can see the message archive you may be able to remind yourself of the sequence of events.
Anyway, anybody uploading a file to that group now is just 'having a laugh' because it hasn't had anything to do with BBC BASIC for Windows for many years. Even being able to upload files at all is an anomaly, because since messages can't be posted no discussions about the file(s) could take place.
I would just ignore any uploads there as rogue and irrelevant.
Richard.
|
|
Logged
|
|
|
|
|
