All, I am trying to run a loop that places two different items on each sheet for a list of sheets. My code block runs successfully, but nothing new appears on the sheets. The functions this uses are:
*ScheduleOnSheet.BySheetScheduleLocation
*Viewport.BySheetViewLocation
I have verified the following mechanisms are working properly:
- My lists of sheet elements, view elements, and locations all have the right information
- The list “lst” proves that the loop runs correctly
- (commented out) I can directly call the Viewport and ScheduleOnSheet functions and they DO successfully place what I need on each sheet. The problem with this is, I don’t know how many lines of this to write because the total amount of sheets/views will not be the same each time. That is why a loop is preferred for this.
Current Script:
A couple problem-areas:
The user-defined functions I made have no effect, even if I call them directly (outside of the loop). I believe those are coded properly, but I don’t believe the Viewport and ScheduleOnSheet functions are performing anything.
If I directly use those functions Viewport.BySheetViewLocation and ScheduleOnSheet.BySheetScheduleLocation in my loop, sometimes I can get an error that these functions are not a static method. From my experience, placing them in a user-defined function and then using that function in a loop will resolve that issue. Also, sometimes, nothing is placed on the sheets with no errors.
Does anyone know what could be the problem? Do those two DesignScript functions dislike being placed in a user-defined function for some reason? Do they dislike being placed in a loop for some reason?
Any input would be great! Thanks. I will try and reply to any follow-up questions as quickly as I can.
Definitions need to return something. Try adding a return = before the function you are calling.
Also you have added a lot of additional unnecessary complexity here. The definitions are any faster than calling the single functions directly. Also I can’t see the inputs, but I think that the imperative code need not be used - lacing will work itself out here more efficiently.
I have the imperative code simply to make my code easier to read, so if it has errors, I can more easily understand what’s happening. With time, I am sure that may not be as necessary.
If I exclude the functions, it looks like this, and no items appear on the sheets:
This is confusing, because using them one-at-a-time (commented out) works properly.
Thanks to your tip, my functions now work if I use them one-at-a-time (commented out). Unfortunately, these also do not work in my loop either. Here is what that looks like:
I don’t think the imperative is working - it just doesn’t like being used like that. Let the lacing do its magic and see what happens. If that fails link or post a model to run this in and your dyn and I can try to look into this tomorrow.
1 Like
Thanks for your input, jacob. Apologies I didn’t quite understand what you said earlier. I need an Imperative block to run a While loop, which I figured was necessary to place each of the two views onto each sheet.
Are you suggesting I avoid using a While loop as well?
No loops required. I am amazed. All views are placed on their respective sheets.
1 Like
Can you please expand on why the Imperative block with a While loop was not the approach in this case? I would love to learn more about its behavior.
Glad you worked it out!
Dynamo by default utilizes “associative programming” which enables list levels and lacing support. This is rather unique among programming languages, basically each function looks at the input(s) and decides how to behave based on the structure which it receives.
If you provide a function a list and an item it takes the one item repeatedly against all of the items in the list (longest lacing). If you provide a list and a list it takes the shortest list and gets the matching number of items from the longer list and mixes index to index (shortest lacing). The association of inputs to each other happens automatically based on the structure provided. As a result there is no need to say “for thing in list of things” or ‘for index in range of indexes’ or other textural loop structure. This is intended to allow for inexperienced coders to ‘jump right in’.
However in most other languages (Python, C#, etc.) it is imperative that you declare the association yourself; no assumptive association can be made. This is where for item in listofItems: or foreach (class object in listOfObjects) { } comes into play.
There are some instances where you want to do something repeatedly - say removing a random area from a surface until the surface area is reduced by 10%. In such cases Dynamo need to overwrite the surface in memory repeatedly, and this is where forcing the [imperative] code block comes into play. Usually these should be avoided when possible as associative actually outperforms them by a significant margin due to the nature of Dynamo’s engine, but when they are needed they are really useful to those who don’t want to fight engine changes ordeal with compiling their code (C#).
Hopefully this helps - you might also want to check out the Dynamo office hour on the topic of Design Script: https://www.youtube.com/watch?v=SndGdDpeY84&list=PLdlF7MirPEC2yNFTGymESd3t7Xosfk9c2&index=37&t=107s
1 Like
