Hi @ngnam1988. I think I see one or two details that may need to be fixed to make this work. When I copied your code into a new iLogic rule in a test drawing with one page and several ballooned things, commented a few lines, corrected a couple things, and added a line or two, I think I got it working. Since my drawing did not have any of the problems you were looking for, I just eliminated that one 'check' If...Then statement, then commented out your final message in the loop, and added my own smaller/simpler one. Then I corrected the Point2d type that you were creating to make it a real Point (3D) type, and just added a zero in there for the Z spec. Then made the zoomed window area smaller, because I use inches, and it was zoomed way out for me. Then I added a line to un-select the Balloon object before the end of each loop, so it does not stay selected. Then, when I ran that, it did as I expected.
Dim _InventorApp As Inventor.Application = ThisApplication
Dim oDOC As DrawingDocument = _InventorApp.ActiveEditDocument
Dim oSelectSet As SelectSet = oDOC.SelectSet
oSelectSet.Clear()
For Each oSheet As Sheet In oDOC.Sheets
oSheet.Activate()
For Each oBalloon As Inventor.Balloon In oDOC.ActiveSheet.Balloons
'MsgBox(oBalloon.BalloonValueSets.Item(1).ItemNumber)
'If oBalloon.BalloonValueSets(1).OverrideValue <> "" And oBalloon.BalloonValueSets(1).OverrideValue <> oBalloon.BalloonValueSets(1).ItemNumber Then
oSelectSet.Select(oBalloon)
Dim oCamera As Inventor.Camera = _InventorApp.ActiveView.Camera
Dim NewTargePnt As Inventor.Point = _InventorApp.TransientGeometry.CreatePoint(oBalloon.Position.X, oBalloon.Position.Y, 0)
oCamera.Target = NewTargePnt
Call oCamera.SetExtents(5, 5)
oCamera.Apply()
MsgBox("Review Selected Balloon", , "")
oSelectSet.Remove(oBalloon)
'MsgBox("ITEM " & (oBalloon.BalloonValueSets(1).OverrideValue & " SHOULD BE " & oBalloon.BalloonValueSets(1).ItemNumber))
'End If
Next
Next
Unfortunately, the message is always in the center of the screen, so it is always over top of the selected balloon we want to look at. 😄
If this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.
Wesley Crihfield
(Not an Autodesk Employee)
Thanks @WCrihfield
I got a problem. I don't know why the view changed as these pictures. Do you get same error, or there's something wrong in code? I tested with Inventor 2018.3.10 and 2023.4.1
Thanks,
Hi @ngnam1988. I did not notice yesterday when I tested the code, but after testing it again today on another drawing, yes. I also get that odd problem. That is wild. It seems to not only move where each balloon's leader pointer is, but it also leaves them really messed up afterwards, because I can no longer just move them back into their original positions. And using the UNDO button does not undo the issues it causes either. When I grab the end of the balloon's leader pointer to move it, it instantly jumps way down and to the left on the screen, away from my mouse pointer, but then still tracks with the movements of my mouse, but at a large offset distance from the mouse's pointer. And every additional time I try to grab the end of it, it just jumps away again, making it seemingly impossible to fix. Then, when I delete those existing balloons, and try to place new balloons, I can not get that to work either. Even trying to place dimensions on stuff in the drawing does not seem to work anymore after that point. It's like the pointer coordinates have been permanently moved from the mouse pointer's position, to some other position. This sure seems like a bug in the software.
Wait...I think I got something to work in the alternate iLogic rule I was testing with this morning. I included specifying the 'Eye', not just the 'Target' when setting the camera in the loop, but that did not seem to fix it on its own. When I added the View.Update line after the loop, that seemed to correct the very odd behavior. Then after running the rule, it the balloon pointers have not moved, and they still act normally afterwards, and other stuff is still acting normally. Below is the similar rule that I was testing with this morning, which seems to work better now.
If ThisDoc.Document.DocumentType <> DocumentTypeEnum.kDrawingDocumentObject Then Return
Dim oDDoc As DrawingDocument = ThisDoc.Document
Dim oSS As SelectSet = oDDoc.SelectSet
oSS.Clear()
Dim oTG As TransientGeometry = ThisApplication.TransientGeometry
Dim oSheets As Inventor.Sheets = oDDoc.Sheets
Dim oOrigSheet As Inventor.Sheet = oDDoc.ActiveSheet
For Each oSheet As Sheet In oSheets
oSheet.Activate()
Dim oBalloons As Inventor.Balloons = oDDoc.ActiveSheet.Balloons
For Each oBalloon As Inventor.Balloon In oBalloons
oSS.Select(oBalloon)
Dim oCamera As Inventor.Camera = ThisApplication.ActiveView.Camera
Dim oTarget As Inventor.Point = oTG.CreatePoint(oBalloon.Position.X, oBalloon.Position.Y, 0)
oCamera.Target = oTarget
oCamera.SetExtents(2, 2)
oCamera.Apply()
MsgBox("Review Selected Balloon", , "")
oSS.Remove(oBalloon)
Next
Next
oOrigSheet.Activate
ThisApplication.ActiveView.Fit()Maybe someone from Autodesk could take a look at this process and figure out what was going on with that earlier process, or maybe get it reported to their folks on the inside as a process that causes buggy behavior, so they can fix it. You will likely want to add your inspection check and message back in there.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @J-Camper @WCrihfield
It is possible with selected a dimension line?
I'm trying adjust code but can't get correct result
All I can think of is that I must have copied the wrong version of the code to the forum window in 'Message 4', because I mentioned right in second paragraph of that response about adding in the code for moving the eye also, then adding in the code for updating the view afterwards. But I do not see that code in the code I posted there. I did have an iLogic rule that was working just fine in multiple tests before posting that response. I know I had at least 3 different versions of that rule copied across 3 or more different drawing documents, with slightly different code in each one, so that is probably where the mistake happened.
Anyways, I do not really see the difference between the long route process you are doing there, and simply specifying the two 3D coordinates directly. My working code just specified the 'Target' Point being at zero Z depth, then the 'Eye' at One Z depth, which seemed to work just fine. You are specifying the initial Z depth for the balloon's current location using the Z depth of the original Target. Well the Z depth of the Camera in a normal drawing is already at zero, so I just specified Zero directly there. And normal the 'Eye' Z depth of the Camera in a normal drawing is always in the positive direction, with the X & Y at the same values as the 'Target'. Then you are getting the vector from the camera's current 'Target' point to that balloon location point. Then you are copying the current 'Target' and 'Eye', and moving those two points by the vector you obtained, and using those two copied, moved points to specify the new 'Target' and 'Eye' locations. It seems like the same outcome could be achieved by just directly specifying the location you want the target to be, at the zero Z-depth, then specifying the same exact X & Y coordinates, with a positive Z depth, for the 'Eye', without having to go through all of those extra steps.
For example:
Dim oCamera As Inventor.Camera = ThisApplication.ActiveView.Camera
oCamera.Target = oTG.CreatePoint(oBalloon.Position.X, oBalloon.Position.Y, 0)
oCamera.Eye = oTG.CreatePoint(oBalloon.Position.X, oBalloon.Position.Y, 1)
oCamera.SetExtents(2, 2)
oCamera.Apply()
I know that the original 'Eye' point may not have actually been at 1 unit above zero, but I do not believe its actual height is important, as long as it is directly above the 'Target' point, because we are setting the 'Extents' right after that step, which adjusts the size of the viewing area. Instead of specifying the specific 'Eye' point, we could have also specified the oCamera.UpVector property with a simple UnitVector that is just defined using 0,0,1 inputs. In this 2D environment, that would tell it that the 'up' direction for the observer is in the positive Z direction (above the sheet).
I also created a simple, quickie iLogic rule to correct the camera issue in the first drawing document that I tested my original code in, which corrected the issues it created. It uses the same technique, and worked just fine.
Dim oTG As TransientGeometry = ThisApplication.TransientGeometry
Dim oCamera As Inventor.Camera = ThisApplication.ActiveView.Camera
oCamera.Target = oTG.CreatePoint(0, 0, 0)
oCamera.Eye = oTG.CreatePoint(0, 0, 1)
oCamera.ViewOrientationType = ViewOrientationTypeEnum.kFrontViewOrientation
oCamera.Apply()
ThisApplication.ActiveView.Fit(True)Edit: But I guess we could just use oCamera.Target.Z instead of 0 (zero) when setting the Z-depth of the new 'Target' point, and oCamera.Eye.Z instead of 1 (one) when setting the Z-depth of the new 'Eye' point, since doing so is still simple enough, and is cleaner. And I may have been wrong about just specifying the Camera.UpVector instead of specifying the new 'Eye' point in that process. In some testing, that cause my sheet to go crooked (at an angle). To fix the angled sheet afterwards , I set the Camera.ViewOrientationType property to the kFrontViewOrientation variation, in addition to the (0,0,0) Target & (0,0,1) Eye specs, in the correction rule. That stuff is pretty tricky, and I do not usually mess with this stuff in a drawing environment, so I learned (or re-learned) some stuff while going through this, which is always a bonus.
Wesley Crihfield
(Not an Autodesk Employee)
My very similar inspection code always returned a simple 0 (zero) value for the 'Target' Z coordinate, instead of an extremely small value. Not sure what the difference may be between my system and yours. But you had the right idea about reusing the original Z-depth values of the target and eye, because it is definitely cleaner, and the proper way to go.
Wesley Crihfield
(Not an Autodesk Employee)
@J-Camper Yes. I zoomed in and out small distances in some tests. Zoomed out until sheet was either barely a dot, or completely out of site for some checks. Zoomed all the way in until all I could see was the black interior of a single text letter for some checks. Sometimes with the sheet inside the viewing area, and other times with the sheet off one side of the viewing area while testing at either range. Checked at least 12-15 log results, about 2-3 times now. I never got a non-zero value for Camera.Target.Z property. I am using 2024.0.1 version, inches document units, and 8.5 inch x 11 inch sheet size. Some of the other X & Y values are showing all the way out to around 12-13 decimal places. I know the Double data type goes out to about the 15th decimal place. Hard telling what could cause slightly different values like that. Might be something like system hardware specs, system settings, how the zooming is done, or something else. I use a 3DConnexion SpaceMouse Pro (3D mouse) for most of my zooming (and while testing), but sometimes use mouse wheel (Logitech Ergo M575), on a Dell Precision series tower PC with Windows 10 Enterprise 64-bit, Intel Xeon 3.7GHz processor with what looks like 16 cores, and 64 GB RAM. This computer is nearing its retirement date according to the standards of where I work though.
Wesley Crihfield
(Not an Autodesk Employee)
