iLogic Error Produced by Return Statement in VB Function...

[Anonymous]

Using  Autodesk Inventor 2019 Professional
I am experiencing a strange circumstance.  When I embed iLogic functions (not subprocedures) into a part or assembly model created by one specific  coworker on their machine, two errors are produced by the "Return" statement:
a. "Property access must assign to the property or use its value."
b."Method arguments must be enclosed in parentheses."
Before anyone asks... yes, I am using a Sub Main() subprocedure to call my functions and subprocedures. I've been doing this a long time and this is the first time I've ever gotten these errors.  All code being used has been used for 5 years now without issue.  There is NO problem with the code.  It has something to do with the document.  All code works on identical documents created on anyone else's system.
 
 I've tested with sample functions. ANY function with a Return statement produce these errors, and ONLY in part/assembly models created on this one guy's machine, and ONLY within internal rules. If I link the rules externally, I do not get the errors. My security options are set to "All events enabled".  So, my question is... is there a document-level setting which can prohibit functions in internal iLogic rules from running?

kelly.young has embedded your image for clarity.

[Anonymous]

I could not figure out how to edit my previous post, so I'm adding this reply for additional info.
 

All Inventor models produced from this one computer are generating the same errors. It is a new computer and setup, so the only thing we can surmise is that possibly it is a document-level setting which might be the cause.

[Anonymous · Accepted solution]

Okay. I figured it out.  The guy creating the documents on that machine created a user parameter in each document named 'Return', which of course cause the conflict. All is corrected and working now!

Note to self: Never allow users to name a parameter anything which exactly matches an iLogic/Visual Basic keyword, method, event, member, or property name...

[MjDeck]

Most keywords and standard VB identifiers can be used as Inventor parameter names without causing a problem for iLogic. We might be able to make a change in a future release so that Return can also be used.

[MjDeck]

Sorry, I spoke too soon. There will be similar problems with most keywords. In rules that are stored in documents, iLogic gives priority to the Inventor parameter names in that document.

You can work around this by taking advantage of the fact that Inventor parameter names are case sensitive. If you rename the Inventor parameter to "return", then Return will work as a keyword in the rule.

Another workaround would be to put code in an external rule, and call it from rules in the documents.

[Anonymous]

That information is good to know! However, for my team anyway, I consider it to be a better programming practice and discipline to simply avoid implementing any key words or identifiers in one system which is used in the other. To me, Autodesk adding VB/iLogic keywords which might be used as parameters in Inventor isn't at the top of my list.  I'm quite happy with Inventor as it is. There are only 2 things I would change or improve upon:

1. This one really gets under my skin - there do not seem to be any (or few at most) books on programming the Inventor API with VB, C#, or C++. I like physical books that I can hold in my hands while I learn something and internet access is often iffy at home where I live.  There are plenty of web pages and white papers online which cover the topics, but no books.  AutoCAD has at least one or two books for programming its API with .NET.  Somebody please write some books for programming the Inventor API. On this subject, it seems (it may not be the case, but it appears to be) that Autodesk goes out of its way to not provide thorough educational documentation on programming the API - except to those on paid subscription.  It seems like Autodesk doesn't want people to learn how to master Inventor programming until after they have purchased a copy of it.  If I had a product I was trying to sell, I would make the information on how to use it as readily available as possible, thereby increasing the number of people who are likely to decide to either start using my product, or continue using it.  People don't just need the software made available to them, they need a practical means of learning to use it as well.  And having the API documentation scattered here, there, and everywhere on web pages and white papers really isn't nearly as practical as combining it all into one or two books that someone can hold in their hand, even if its in the form of an eBook or singular PDF they can peruse through on their e-reader.

2. Please change the Open dialog form. When I need to open a document with this dialog, I have to use the drop-down field entitled "Look in:", which is linear in function. When I am searching through nested network folders to look for an old model or drawing document of which its directory is not in my workspace, it can take forever to find what I'm looking for. I often already know the folder path. But in the current Open dialog, I can't paste the folder path to navigate directly to it like I can in the Open dialog with other applications and with Windows file explorer. Please adapt the open dialog to where we can paste a folder path in there instead of only being limited to searching through the drop-down directory tree.
 

Okay, I've had my morning coffee now.  Fruitless rant session over. LOL

[MjDeck]

I agree that the documentation could be better. A book would be a good idea.

Have you looked at the Mod the Machine blog? 

About your second point: you can paste a folder path into the "File name:" field, near the bottom of the dialog.