Place code/comments into ALL modules automatically

I have the need to place code/comments into ALL modules and routines automatically. This would be nice for Open Source stuff (commenting) and also for making a call at the start of a routine (debugging).

I found that Introspection-System somewhat helpful - but do not know how to write something there.

Is there any way to place code automatically at the begin of ALL routines? Constructor for Methods? Any tools like ARBED able to do that?
https://tempel.org/arbed

Thanks for any help or direction.

For my own projects, I do this right in the .xojo_code files on disk. You need to be very careful, but it is possible if you don’t change the overall structure of the file… and if you break it, you buy it so to speak.

The obvious rule of caution: make a copy of the project file right next to the one you’re editing, so you can quickly check the edited file and, if it fails, replace with the copy.

1 Like

Thanks, this is what I also thought about … but did not like. Isn’t there any capability “inside” Xojo (Introspection?) to handle that?

Thanks!

I requested template macros many, many moons ago, but that request doesn’t seem to have made the shift from fogbugz to the latest iteration.

I’d love to be able to automate any new method so that they are automatically populated with something like this:

DebugIndentLevel = DebugIndentLevel + 1
Debug.Print CurrentMethodName + ": Enter"
// Add Method code

Debug.Print CurrentMethodName + ": Exit"
DebugIndentLevel = DebugIndentLevel - 1

The Debug module is my main testing tool since we still don’t have watch points.

1 Like

Introspection is for runtime in your app. Not for editing in the IDE.

Norman made a script for this a while ago.

Hmmm. I just want to know what happens, WHILE it’s running (Introspection does it). The way to get this is to put a piece of code everywhere it’s needed. I am using Dash for that now - it can even ask for parameters - and is in use for other IDEs also:

But the code “blows up” a bit this way - it would be better to place it in a kind of constructor for the “Method-Method”?

Another way to look at it: If you use the “Profile” function - which I like VERY much in Xojo - you see the names of the objects/methods together with the time.

Is there any way to get THIS NAME as a text/string inside my routine itself? I still suffer with the parents name here …

Yes:

CurrentMethodName

It is an automatic constant available in each method / event

Yes, I am using this today. In hundreds of routines. And the name of the parent? Is there a way to crawl back the call history? Thanks, Jeremy!

The only way to crawl back the call history, at least that I know of, is to raise an exception and catch it.
The stack trace will contain a somewhat readable version of the call history.

Such as this (topmost item is the method that raised the exception)

arrestDB.!lastInsertID%y%yo<Xojo.Core.Dictionary>
vCustomize.vCustomize.AddProductProcess%%o<vCustomize.vCustomize>yo<RuntimeException>o<Xojo.Core.Dictionary>
Delegate.IM_Invoke%%yo<RuntimeException>o<Xojo.Core.Dictionary>
arrestDB.Event_PageReceived%%o<arrestDB>yi8o<Xojo.Core.MemoryBlock>
JLY_ThrottlingSocket.Event_PageReceived%%o<JLY_ThrottlingSocket>yi8o<Xojo.Core.MemoryBlock>
_ZN14HTTPSocketData12PageReceivedER13HTTPSocketImpRK4TextxP13RuntimeObject
-[XOJConnectionDelegate connectionDidFinishLoading:]
_CFURLStorageSessionCopyIdentifier
2
_CFStreamErrorFromCFError
1
<redacted>
1
_CFURLStorageSessionCopyIdentifier
CFArrayApplyFunction
_CFURLStorageSessionCopyIdentifier
1
<redacted>
3
CFRunLoopRunSpecific
GSEventRunModal
<redacted>
UIApplicationMain
_Z14runIOSMainLoopv
Xojo._RuntimeRun
_Main
main
1 Like

I’d love to be able to automate any new method so that they are automatically populated with something like this:

Mac User:
I use TextExpander to accomplish this task. I have expander snippets for many different types of code


Example for the Event Handler of a Control

Const CONTROL_NAME As String = "NameOfControl"
Const EVENT_NAME As String = "Pressed"
// WINDOW NAME: NameOfWindow 
// DATE/TIME: 2023 § 08/17/23 08:44 - Bearboat Software. 230817_0844
// DESCRIPTION: None



Exception err As RuntimeException
  Var contextInformation As String = CurrentMethodName + EndOfLine + EndOfLine + "WINDOW: " + WINDOW_NAME + EndOfLine + "CONTROL: " + CONTROL_NAME + EndOfLine + "EVENT: " + EVENT_NAME
  If Not ErrorHandling.HandleException(err, contextInformation) Then Raise err
  System.DebugLog "Exception - " + CurrentMethodName

So when I start entering the code for a Control Event, I just use the keystroke shortcut for this and it all appears in the code editor as a start. NameOfControl and NameOfWindow are replaced manually with what is appropriate. Pressed is the default but it can be replaced when necessary.

It installs my error handling system automatically. It time stamps the date and time the code was written automatically. All this helps if a need arises to search for some code in the IDE,

I suspect that I would like a well-implemented template macro system, but this has worked well for me.

1 Like

Ouch! Why are you doing that? CurrentMethodName contains the window, the control AND the event name.

2 Likes

I wrote a little blog post about this:

Tip of the day: Where are we in the code?

1 Like

This is not to sell my particular choices. :thinking:
I am just pointing to the TextExpander tool to get macro like function. What someone would put in their macro would obviously be up to them.

I use the control name and event to help me with searching and provide context to me when I review code and as a source for copy paste.

Ouch! Why are you doing that?

Remember it is painless. It. Is automatic.

Since the addition of CurrentMethodName your code has been useless.

Most interesting parts of Christians code:

  • Introspection.GetType(Self).name (did not know)
  • Introspection.GetType(Me).name (… either)
  • The fact that I have to raise an event to get the caller name (ooops …)

Still two complaints about that:

  • Not (realistic) automatable for each control, method …
  • The try … catch + raise will take lots of execution time

… though they are all simple properties which are not accessible AND that obviously methods and controls are not “really” objects - because it lacks the “super”-constructor for the method and the control?

Thank you Christian - nice peace of code you wrote. May be they should put it ito the codumentation?

Well, we get the call stack via raising an exception when reporting an error.
That code runs usually once when reporting an error and performance doesn’t matter then.

And Xojo Inc. can add text to their documentation if they like.

I just discovered TextExpander and immediately fell in love with it. Our support and sales teams use it constantly, so we already have a corporate license!

I’ll have to add new !XMETHOD and !XEVENT to my finger muscle-memory.

1 Like