|
|
|||||||
I have added a few more IFINGROUP labels to a logon script and now I get the following Application Popup Error when the user executes the logon script: Application popup: KIX32.EXE - Application Error : The exception unknown software exception (0xc00000fd) occurred in the application at location 0x0040c66e. My question...Is there a limitation on the amount of labels that can be used with KIX 3.50.0.0? I bring this up because the script runs without error if I comment out a few of the labels. Thanks in advance Jay |
||||||||
|
|
|||||||
Hmmm... labels imply GOTO which implies spaghetti code... tsk, tsk What if you used different words for the labels you are commenting out? Maybe you used a reserved word. What if you used something newer than 3.50? What if you got rid of the spaghetti? |
||||||||
|
|
|||||||
hmm... well, if there is such a limitation, it's unknown one. does that error occur only when logging on or also when ran manually? |
||||||||
|
|
|||||||
Hmmm... He said "I have added a few more IFINGROUP labels" Now, we know "IF" is a conditional construct, not a label. Also, InGroup() is a function, not a label. Have to wonder where "label" has anything to do with what. I think there is just some bad code in there and he is commenting it out. |
||||||||
|
|
|||||||
good quess but can't be sure before I see some... |
||||||||
|
|
|||||||
Les, this is the longest spaghetti noodle the world has ever seen. With that being said and my knowledge of KIX (I wouldn't even consider myself a "starter") combined with being the lucky one to be tasked with this -- I kind of just wanted to follow the existing "model" or spaghetti as you refer to it and append the entries to the end and not change the version of KIX. When you refer to a reserved word, do you mean using a word that I have already used as a label? It errors out when run manually as well... Here's what the a portion of the script looks like: :g217 IF INGROUP ("G-Geodax-New-Bern-NC") USE L: "\\US-NEW216-DFOP1\APPS" USE O: "\\US-NEW216-DFOP1\@userid$" USE K: "\\US-NEW216-DFOP1\COMMON$" GOTO g218 Else GOTO g218 :g218 IF INGROUP ("G-Geodax-Pittsburgh-PA") USE L: "\\US-PIT817-DFOP1\APPS" USE O: "\\US-PIT817-DFOP1\@userid$" USE K: "\\US-PIT817-DFOP1\COMMON$" GOTO g219 Else GOTO g219 :g219 IF INGROUP ("G-Geodax-Raleigh-NC") USE L: "\\US-RAL302-DFOP1\APPS" USE O: "\\US-RAL302-DFOP1\@userid$" USE K: "\\US-RAL302-DFOP1\COMMON$" GOTO g220 Else GOTO g220 :g220 IF INGROUP ("G-Geodax-Roanoke-VA") USE L: "\\US-ROA223-DFOP1\APPS" USE O: "\\US-ROA223-DFOP1\@userid$" USE K: "\\US-ROA223-DFOP1\COMMON$" GOTO g221 Else GOTO g221 :g221 IF INGROUP ("G-Geodax-Wilmington-NC") USE L: "\\US-WIL218-DFOP1\APPS" USE O: "\\US-WIL218-DFOP1\@userid$" USE K: "\\US-WIL218-DFOP1\COMMON$" GOTO DONE Else GOTO DONE ENDIF ONE ;run "sms.bat" :SEEYA |
||||||||
|
|
|||||||
reserved word means that you have a label like: :ingroup or: :substr well, get the point. kixtart commands, functions and macros and "AND", "OR" and "THEN" are reserved words in that version... most likely. |
||||||||
|
|
|||||||
What I would do is this: Run over to MCA's place and grab a program called Kixstrip Run it like this: c:\>kixstrip script.kix output.txt Notepad output.txt and look for anything suspicious ... post the output here if you want further analysis ... this will at least eliminate any possible funky syntax/mismatched quote/logic issues ... -Shawn |
||||||||
|
|
|||||||
"Reserved words" are words that Ruud set aside as "sacred cows" and cannot be used by us mere mortals. I just want to be clear on what you mean by "LABELS". Are you doing an IF bla GOTO LABEL? Code: If Ingroup('bla') edit: OK, I see you edited your post after I posted. |
||||||||
|
|
|||||||
Hey! You are missing a whole bunch of ENDIFs. Every IF must have a matching ENDIF! |
||||||||
|
|
|||||||
You should change the subject to "KIX ver. 3.50.0.0 and limitations with amount of stack space". Every time KiX encounters an IF, it pushes to the stack. When it finds the ENDIF, it pulls from the stack. You MUST match the number of IFs with ENDIFs. Ruud does do stack cleanup to compensate for sloppy code but it has its limits. |
||||||||
|
|
|||||||
actually, the code is screwed up in logic pretty bad. but basically, something like should fix up some: Code:
|
||||||||
|
|
|||||||
les talks the real deal here... |
||||||||
|
|
|||||||
That whole IF construct should be replaced with a SELECT CASE construct since only one of the IFs can prevail, the last TRUE IF. There is no point in enumerating group membership once you have a TRUE result so the mutually excluse CASE would be better. OH, and it gets rid of those damn GOTOs! |
||||||||
|
|
|||||||
And upgrade to the future, a.k.a Kixtart 4.23 |
||||||||
|
|
|||||||
The future is 4.5, the present is 4.23. Well.. unless you are stuck in the past and want to get back to the future. |
||||||||
|
|
|||||||
I downloaded KIX 4.23 and the script ran fine without having to modify any lines. Thanks for all of your help! And please add my forum account to the KIX Scripting Hall of Shame . |
||||||||
|
|
|||||||
That only proves that 4.23 is more forgiving of sloppy code. The real "shame" is that you did not clean up the code. Sooner or later, 4.23 too will reach its limit of tolerance. |
||||||||
|
|
|||||||
I plan on changing the script, I just need to get more familiar with KIX thru white papers, this forum, etc. |