TBC Macros and Extensions

So far this never has been an issue, and I never paid much attention to it. The Trimble sample macros also show it in mixed order.

I'm currently running 2025.10 and ran into an issue with one of my older macros that explodes text into linework, potentially creating thousands of linestrings and deleting thousands of texts.

If I use it in the following order, it nearly always locks up on executing the second line, sometimes it finishes quickly as well.

                UIEvents.RaiseAfterDataProcessing(self, UIEventArgs())                self.currentProject.TransactionManager.AddEndMark(CommandGranularity.Command)

I let it be and maybe 10 minutes later it finally finished, whereas it finishes always nearly immediately when executed in reversed order.

And in addition, what should be the order at the beginning of the macro then.

        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())or        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)

Hey Ronny,
Internally, the majority (though definitely found instances of other way) are in the following format

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());try {     using (TransactMethodCall failGuard =                new TransactMethodCall((ITransactionCollector)TranCtrl))            {                    DoOperation();                    failGuard.Commit();            }            TranCtrl.AddEndMark(CommandGranularity.Command);}finally {                UIEvents.RaiseAfterDataProcessing(this, new UIEventArgs());}

A good number add a block to pause the graphics during these operations. 

worldView.PauseGraphicsCache(true);// try/catch blockworldView.PauseGraphicsCache(false);

Again, I saw a few instances of the swapped version, but I would estimate it was 9/10 times the above. 

So far this never has been an issue, and I never paid much attention to it. The Trimble sample macros also show it in mixed order.

I'm currently running 2025.10 and ran into an issue with one of my older macros that explodes text into linework, potentially creating thousands of linestrings and deleting thousands of texts.

If I use it in the following order, it nearly always locks up on executing the second line, sometimes it finishes quickly as well.

                UIEvents.RaiseAfterDataProcessing(self, UIEventArgs())                self.currentProject.TransactionManager.AddEndMark(CommandGranularity.Command)

I let it be and maybe 10 minutes later it finally finished, whereas it finishes always nearly immediately when executed in reversed order.

And in addition, what should be the order at the beginning of the macro then.

        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())or        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)

Thanks Bryce,

currently I can't reproduce it anymore, it somehow fixed itself. I'll keep experimenting when I find the time.

I assume

TranCtrl.AddBeginMark(CommandGranularity.Command);

is executed right before?

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());

I usually trigger the PauseGraphicsCache. 

One of the biggest bottlenecks I found is the Progressbar, especially in loops that run 10.000 or even > 100.000 times. Instead of updating it that often it may just update a handful of times before the macro finishes.

Therefore, I've changed nearly all my macros to time-based updating. This can change a macro from the bar slowly crawling across to finishing nearly instantly.

i.e.

                j = 0                time1 = datetime.now()                for sn in objlist:                    texto = self.currentProject.Concordance[sn]                    j += 1                    if (datetime.now() - time1).seconds > 0.2: # or sometimes even 0.5                        if ProgressBar.TBC_ProgressBar.SetProgress(math.floor(j * 100 / objlist.Count)):                            break   # function returns true if user pressed cancel                        time1 = datetime.now()

Another bottleneck is changing selected objects (not using a serial number list and not clearing GlobalSelection) and sometimes having AnzToolboxes "Show Line Direction" enabled while a macro runs. The "Show Line Direction" can slow standard TBC functions down quite a bit as well. 

Hey Ronny,
Internally, the majority (though definitely found instances of other way) are in the following format

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());try {     using (TransactMethodCall failGuard =                new TransactMethodCall((ITransactionCollector)TranCtrl))            {                    DoOperation();                    failGuard.Commit();            }            TranCtrl.AddEndMark(CommandGranularity.Command);}finally {                UIEvents.RaiseAfterDataProcessing(this, new UIEventArgs());}

A good number add a block to pause the graphics during these operations. 

worldView.PauseGraphicsCache(true);// try/catch blockworldView.PauseGraphicsCache(false);

Again, I saw a few instances of the swapped version, but I would estimate it was 9/10 times the above. 

So far this never has been an issue, and I never paid much attention to it. The Trimble sample macros also show it in mixed order.

I'm currently running 2025.10 and ran into an issue with one of my older macros that explodes text into linework, potentially creating thousands of linestrings and deleting thousands of texts.

If I use it in the following order, it nearly always locks up on executing the second line, sometimes it finishes quickly as well.

                UIEvents.RaiseAfterDataProcessing(self, UIEventArgs())                self.currentProject.TransactionManager.AddEndMark(CommandGranularity.Command)

I let it be and maybe 10 minutes later it finally finished, whereas it finishes always nearly immediately when executed in reversed order.

And in addition, what should be the order at the beginning of the macro then.

        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())or        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)

AddBeginMark is done before the guard (so after RaiseBeforeDataProcessing).  

// 
RaiseBefore

AddBegin
Guard
(Commit in guard using)
AddEnd
RaiseAfter

For progress, I would say the majority of commands do not utilize it for quick operations and just transact.
The pattern I've seen internally if the command does utilize progress is they internally calculates 0->100 and update on whole value increments (1, 2, 3, ..., 100). Not the best, but seems like internally devs ran into a similar hiccup and opted to solve it by throttling the update to progress :P

We'll forward the issue to ANZ about the selected objects and their command and hopefully they can throw a patch in. 

Thanks Bryce,

currently I can't reproduce it anymore, it somehow fixed itself. I'll keep experimenting when I find the time.

I assume

TranCtrl.AddBeginMark(CommandGranularity.Command);

is executed right before?

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());

I usually trigger the PauseGraphicsCache. 

One of the biggest bottlenecks I found is the Progressbar, especially in loops that run 10.000 or even > 100.000 times. Instead of updating it that often it may just update a handful of times before the macro finishes.

Therefore, I've changed nearly all my macros to time-based updating. This can change a macro from the bar slowly crawling across to finishing nearly instantly.

i.e.

                j = 0                time1 = datetime.now()                for sn in objlist:                    texto = self.currentProject.Concordance[sn]                    j += 1                    if (datetime.now() - time1).seconds > 0.2: # or sometimes even 0.5                        if ProgressBar.TBC_ProgressBar.SetProgress(math.floor(j * 100 / objlist.Count)):                            break   # function returns true if user pressed cancel                        time1 = datetime.now()

Another bottleneck is changing selected objects (not using a serial number list and not clearing GlobalSelection) and sometimes having AnzToolboxes "Show Line Direction" enabled while a macro runs. The "Show Line Direction" can slow standard TBC functions down quite a bit as well. 

Hey Ronny,
Internally, the majority (though definitely found instances of other way) are in the following format

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());try {     using (TransactMethodCall failGuard =                new TransactMethodCall((ITransactionCollector)TranCtrl))            {                    DoOperation();                    failGuard.Commit();            }            TranCtrl.AddEndMark(CommandGranularity.Command);}finally {                UIEvents.RaiseAfterDataProcessing(this, new UIEventArgs());}

A good number add a block to pause the graphics during these operations. 

worldView.PauseGraphicsCache(true);// try/catch blockworldView.PauseGraphicsCache(false);

Again, I saw a few instances of the swapped version, but I would estimate it was 9/10 times the above. 

So far this never has been an issue, and I never paid much attention to it. The Trimble sample macros also show it in mixed order.

I'm currently running 2025.10 and ran into an issue with one of my older macros that explodes text into linework, potentially creating thousands of linestrings and deleting thousands of texts.

If I use it in the following order, it nearly always locks up on executing the second line, sometimes it finishes quickly as well.

                UIEvents.RaiseAfterDataProcessing(self, UIEventArgs())                self.currentProject.TransactionManager.AddEndMark(CommandGranularity.Command)

I let it be and maybe 10 minutes later it finally finished, whereas it finishes always nearly immediately when executed in reversed order.

And in addition, what should be the order at the beginning of the macro then.

        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())or        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)

Thanks Bryce,

can you check/confirm that the terrible slow load 2D/3D view is using the fast version of the progress bar update routine.

Because when I build internal lists with i.e. >100.000 coordinates from linestrings/polysegs I have the feeling this is much faster than what the viewform needs to populate. The later one needs to look for color, maybe linestyle etc., but compared to QGIS and ACAD is TBC frustratingly slow. Sometimes it can take minutes to load the data for a view, where QGIS/ACAD need seconds.

https://community.trimble.com/discussion/what-is-this-loading-graphics-for-plan-view-slowdown-anybody-else-411#bm231a4bc0-0ddc-4696-ae96-019102158734

AddBeginMark is done before the guard (so after RaiseBeforeDataProcessing).  

// 
RaiseBefore

AddBegin
Guard
(Commit in guard using)
AddEnd
RaiseAfter

For progress, I would say the majority of commands do not utilize it for quick operations and just transact.
The pattern I've seen internally if the command does utilize progress is they internally calculates 0->100 and update on whole value increments (1, 2, 3, ..., 100). Not the best, but seems like internally devs ran into a similar hiccup and opted to solve it by throttling the update to progress :P

We'll forward the issue to ANZ about the selected objects and their command and hopefully they can throw a patch in. 

Thanks Bryce,

currently I can't reproduce it anymore, it somehow fixed itself. I'll keep experimenting when I find the time.

I assume

TranCtrl.AddBeginMark(CommandGranularity.Command);

is executed right before?

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());

I usually trigger the PauseGraphicsCache. 

One of the biggest bottlenecks I found is the Progressbar, especially in loops that run 10.000 or even > 100.000 times. Instead of updating it that often it may just update a handful of times before the macro finishes.

Therefore, I've changed nearly all my macros to time-based updating. This can change a macro from the bar slowly crawling across to finishing nearly instantly.

i.e.

                j = 0                time1 = datetime.now()                for sn in objlist:                    texto = self.currentProject.Concordance[sn]                    j += 1                    if (datetime.now() - time1).seconds > 0.2: # or sometimes even 0.5                        if ProgressBar.TBC_ProgressBar.SetProgress(math.floor(j * 100 / objlist.Count)):                            break   # function returns true if user pressed cancel                        time1 = datetime.now()

Another bottleneck is changing selected objects (not using a serial number list and not clearing GlobalSelection) and sometimes having AnzToolboxes "Show Line Direction" enabled while a macro runs. The "Show Line Direction" can slow standard TBC functions down quite a bit as well. 

Hey Ronny,
Internally, the majority (though definitely found instances of other way) are in the following format

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());try {     using (TransactMethodCall failGuard =                new TransactMethodCall((ITransactionCollector)TranCtrl))            {                    DoOperation();                    failGuard.Commit();            }            TranCtrl.AddEndMark(CommandGranularity.Command);}finally {                UIEvents.RaiseAfterDataProcessing(this, new UIEventArgs());}

A good number add a block to pause the graphics during these operations. 

worldView.PauseGraphicsCache(true);// try/catch blockworldView.PauseGraphicsCache(false);

Again, I saw a few instances of the swapped version, but I would estimate it was 9/10 times the above. 

So far this never has been an issue, and I never paid much attention to it. The Trimble sample macros also show it in mixed order.

I'm currently running 2025.10 and ran into an issue with one of my older macros that explodes text into linework, potentially creating thousands of linestrings and deleting thousands of texts.

If I use it in the following order, it nearly always locks up on executing the second line, sometimes it finishes quickly as well.

                UIEvents.RaiseAfterDataProcessing(self, UIEventArgs())                self.currentProject.TransactionManager.AddEndMark(CommandGranularity.Command)

I let it be and maybe 10 minutes later it finally finished, whereas it finishes always nearly immediately when executed in reversed order.

And in addition, what should be the order at the beginning of the macro then.

        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())or        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)

Hi Ronny,

The views' loading time and progress bar updates are determined by the number of entities within the project (and their complexity). In terms of the progress bar update routine - it does not have a significant impact on the loading time. I removed all code related to that progress bar and the view loading time has not changed.

I created a few polylines in my project (very small - only a few segments each) and then ran the CopyObjects command until I ended up with 100K entities. With this project, the view took ~5sec to load on my machine. I profiled the performance during loading and noticed that there is some code inside the line drawing portion that takes up a significat chunk of time. I think that part is a good target for optimization, but I'd need to confirm with a dataset that can reproduce the exact problem.

Are you able to share a project which has minute-long loading times? If not, maybe you can create a very small project that contains one or two objects which are representative of the real data you have? I could then run the CopyObjects command (or copy them programatically), recreate the issue you're seeing, and run the profiler to see the painpoint and see what we can do about it.

------------------------------
Arturas Grigorjevas

Original Message:
Sent: 03-05-2026 23:27
From: Ronny Schneider
Subject: correct order of AddEndMark and RaiseAfterDataProcessing

Thanks Bryce,

can you check/confirm that the terrible slow load 2D/3D view is using the fast version of the progress bar update routine.

Because when I build internal lists with i.e. >100.000 coordinates from linestrings/polysegs I have the feeling this is much faster than what the viewform needs to populate. The later one needs to look for color, maybe linestyle etc., but compared to QGIS and ACAD is TBC frustratingly slow. Sometimes it can take minutes to load the data for a view, where QGIS/ACAD need seconds.

https://community.trimble.com/discussion/what-is-this-loading-graphics-for-plan-view-slowdown-anybody-else-411#bm231a4bc0-0ddc-4696-ae96-019102158734

------------------------------
Ronny Schneider

Original Message:
Sent: 03-05-2026 09:36
From: Bryce Haire
Subject: correct order of AddEndMark and RaiseAfterDataProcessing

AddBeginMark is done before the guard (so after RaiseBeforeDataProcessing).  

// 
RaiseBefore

AddBegin
Guard
(Commit in guard using)
AddEnd
RaiseAfter

For progress, I would say the majority of commands do not utilize it for quick operations and just transact.
The pattern I've seen internally if the command does utilize progress is they internally calculates 0->100 and update on whole value increments (1, 2, 3, ..., 100). Not the best, but seems like internally devs ran into a similar hiccup and opted to solve it by throttling the update to progress :P

We'll forward the issue to ANZ about the selected objects and their command and hopefully they can throw a patch in. 

------------------------------
Bryce Haire

Original Message:
Sent: 03-04-2026 23:09
From: Ronny Schneider
Subject: correct order of AddEndMark and RaiseAfterDataProcessing

Thanks Bryce,

currently I can't reproduce it anymore, it somehow fixed itself. I'll keep experimenting when I find the time.

I assume

TranCtrl.AddBeginMark(CommandGranularity.Command);

is executed right before?

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());

I usually trigger the PauseGraphicsCache. 

One of the biggest bottlenecks I found is the Progressbar, especially in loops that run 10.000 or even > 100.000 times. Instead of updating it that often it may just update a handful of times before the macro finishes.

Therefore, I've changed nearly all my macros to time-based updating. This can change a macro from the bar slowly crawling across to finishing nearly instantly.

i.e.

                j = 0                time1 = datetime.now()                for sn in objlist:                    texto = self.currentProject.Concordance[sn]                    j += 1                    if (datetime.now() - time1).seconds > 0.2: # or sometimes even 0.5                        if ProgressBar.TBC_ProgressBar.SetProgress(math.floor(j * 100 / objlist.Count)):                            break   # function returns true if user pressed cancel                        time1 = datetime.now()

Another bottleneck is changing selected objects (not using a serial number list and not clearing GlobalSelection) and sometimes having AnzToolboxes "Show Line Direction" enabled while a macro runs. The "Show Line Direction" can slow standard TBC functions down quite a bit as well. 

------------------------------
Ronny Schneider

Original Message:
Sent: 03-04-2026 08:19
From: Bryce Haire
Subject: correct order of AddEndMark and RaiseAfterDataProcessing

Hey Ronny,
Internally, the majority (though definitely found instances of other way) are in the following format

UIEvents.RaiseBeforeDataProcessing(this, new UIEventArgs());try {     using (TransactMethodCall failGuard =                new TransactMethodCall((ITransactionCollector)TranCtrl))            {                    DoOperation();                    failGuard.Commit();            }            TranCtrl.AddEndMark(CommandGranularity.Command);}finally {                UIEvents.RaiseAfterDataProcessing(this, new UIEventArgs());}

A good number add a block to pause the graphics during these operations. 

worldView.PauseGraphicsCache(true);// try/catch blockworldView.PauseGraphicsCache(false);

Again, I saw a few instances of the swapped version, but I would estimate it was 9/10 times the above. 

------------------------------
Bryce Haire

Original Message:
Sent: 03-03-2026 18:27
From: Ronny Schneider
Subject: correct order of AddEndMark and RaiseAfterDataProcessing

So far this never has been an issue, and I never paid much attention to it. The Trimble sample macros also show it in mixed order.

I'm currently running 2025.10 and ran into an issue with one of my older macros that explodes text into linework, potentially creating thousands of linestrings and deleting thousands of texts.

If I use it in the following order, it nearly always locks up on executing the second line, sometimes it finishes quickly as well.

                UIEvents.RaiseAfterDataProcessing(self, UIEventArgs())                self.currentProject.TransactionManager.AddEndMark(CommandGranularity.Command)

I let it be and maybe 10 minutes later it finally finished, whereas it finishes always nearly immediately when executed in reversed order.

And in addition, what should be the order at the beginning of the macro then.

        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())or        UIEvents.RaiseBeforeDataProcessing(self, UIEventArgs())        self.currentProject.TransactionManager.AddBeginMark(CommandGranularity.Command, self.Caption)

------------------------------
Ronny Schneider
------------------------------