I have a subform that gets used in a main form to pop-up some data lists. In 5.09, it worked without a problem, but since the migration to 6.5, I get an error in the designer indicating
Unexpected: split; Expected: Identifier
on the Option Explicit line in my subforms Options section??? And when I try to change something within the subform (anything!! even put a space anywhere on the form), it gives me this error. If I try to exit designer, it won’t. It just hangs on this form and will not let me out. Even if I hit the little “x” on the tab, it does nothing. I have to logoff, and re-boot my machine entirely. Has anybody seen this, or know of something I can do about it???
Subject: RE: Split is a new Function to LS therefore is a reserved word.
Thanks for the response Bill. I know it is a reserved word (function) in LS. I use this function to split some arrays that are produced. It is fine in R5, but when I try to make ANY change on the subform in R6, it will not allow me to close the form because of the errors. But there are no errors!! All of the variables are defined, everything is declared, and all parameters are set correctly! I can modify the subform with ANY change in 5 and it works! Allows me to save the form, and exit properly. However, in 6, I make ANY change to it, and it will not save because of these errors, so normally, you get a response like “Script errors, click “Yes” to continue editing, or “No” to quit without saving”. I dont even get that or any dialog box allowing me to cancel!! It gets hung up, and will not close the subform, even if i log out of designer AND notes itself!!! The form stays active and will not close!! I have to reboot my machine!! Luckily, notes does not “save” any of the errors or the change I made, and the form is OK when I go back into it on the server. Its like the form gets locked out or caught in a loop or something!! Very bizarre!!
Any ideas?? Anybody??
Thanks…
Mick
Addendum: I made the changes I need on a machine that has R5, saved it (the changes were merely cosmetic to make the subform look better, no additions of fields or script), and then exited. Went over to my machine (R6), and saved it WITHOUT making any further changes, and pushed the save icon on the tool bar immediately, and it saved ok. What is the deal?? Does this mean I am going to have to keep a version 5 machine near (to make changes to forms that produce errors in R6), make all changes there, and then re-save it with a version 6 template to be sure it works!!! What is up with that???
Subject: RE: Split is a new Function to LS therefore is a reserved word.
I think split was not a reserved word in R5, possibly you have it defined in a script library in that application, and when you are loading the form it is picking up your version instead of the 6.5 version hence the failure of the entire client?
Subject: RE: Split is a new Function to LS therefore is a reserved word.
Thanks for the response Evelyn, but split was a function new with R5. That is why I used it, and was able to get a clean “compile” with this application in R5. Good point about a script library, but one is not used in this app. All of the functions used are defined in the “Globals” section of the subform.
I tried a little experiment, and found out that the table that is used in the subform, got corrupted when the migration occurred. I wiped away the table, and rebuilt the entire form (with R6.5 designer), and everything seems to be fine. It is really strange that a corruption of such magnitude, would force me to have to re-boot the machine!! I mean crap, thats all I would need is having some executive going thru this app, and then crashing their machine!!
I realize that things like this do happen, but for this migration we have got thousands of databases, and each form, process, code, anything for every database has to checked!!!
Holy Crap, here comes the overhead, and the overtime… oh well
Subject: RE: Split is a new Function to LS therefore is a reserved word.
Thanks for the response Evelyn, but split was a function new with R5.
No, Split is new with Notes 6.00. I’d lay a bet this is the cause of at least some of the issues you’re experiencing. If you used a function called “Split” in your R5 application, then this is a custom function defined elsewhere. It will cause issues in Notes 6.xx because Lotusscript has that function too. Note that there are other new internal functions like StrToken, Join, Implode and Replace which may also cause problems.
Good to hear you got the issue sorted, even if it does mean reams of work
Subject: RE: Split is a new Function to LS therefore is a reserved word.
Yep, Ben you are correct… my appologies Evelyn, it is with R6. I took that and merely re-named all of the calls to the custome Split function (instead of Split, I renamed the function SplitArraysProcess), and located all calls to the function re-naming them accordingly. Everything works fine now, just kind of bizarre how only the designer seemed to be affected by this, because after the migration, testing the database, and everything was OK. Only after making a change to or attempting to the subform did this occur… why would it not have blown up before in production??
Subject: Not really. It was compiled code. The references to you internal Split function were valid once compiled in R5.
Bill,
I agree that it was compiled code for R5, but this database was moved (migrated) to a 6.5 environment. In that environment, split is a supplied function for notes. As soon as the environment saw that the split was wrong BECAUSE it was custom made in the R5 platform, that means either the R6 platform ignores the fact that it is there UNTIL sombody does want to make a change to it, OR it was somehow still using the R5 template. Which I don’t think the latter could be true at all. I guess it comes down to when a database is copied, moved, replicated to another server with an upgraded environment, what is pushed with it (database design and documents, templates, default database properties of the nsf, etc…). If this was the case I was just wondering why any new documents that were created after being moved to the R6 server, would not have errors, or some screwed up data in the fields on the subform where the split parsed its data??
I also wonder what would happen if after moving the db, do a “Refresh Design” or a “Replace Design” on the db and see what happens…
Anyway, I got it fixed, so I wont worry about it until that happens…
Subject: RE: Not really. It was compiled code. The references to you internal Split function were valid once compiled in R5.
Moving to a new version won’t affect the compiled version, and the compiled version doesn’t change until you recompile the source code. In the compiled version, there’s no “Split” to worry about – there’s a pointer to some code to execute. The source code, at that point, is just some text along for the ride so you’ll have something recognizable to edit later. It’s not until you try to edit it that the source code (and the word “Split”) rears its ugly head, and the compiler has to try to figure out what “Split” means.
