Loop through objects of one or more UserForms
fabien25000
Posted messages
697
Status
Membre
-
yg_be Posted messages 23437 Registration date Status Contributeur Last intervention -
yg_be Posted messages 23437 Registration date Status Contributeur Last intervention -
Hello everyone,
Thank you in advance to everyone who takes the time to read me and help me find some workarounds.
I have an Excel file that works solely through forms.
Everything works relatively well, but I sometimes encounter "quirks," bugs that appear for no apparent reason. The code works, but from time to time, it enters debugging mode, and often all it takes is to move the yellow line back to the beginning of the sub for everything to work correctly again.
I want to specify that all my code sheets have the "option explicit" key and that the project is compiled, so presumably, there are no rogue variables wandering around.
My idea to try to understand these "quirks" would be to create a bug report module, looping through the active userforms and retrieving the values and states of each object. But since each userform is different, it can range from 3 objects to more than a hundred.
Is there a way to make this loop generic, regardless of the number of objects, their types (textbox, combobox, checkbox, optionbutton, etc.), and their names? A kind of code in this idea, but I can’t figure out how to write it.
Being a sales tool that has about a hundred sheets, twenty userforms, and just as many modules, it's impossible for me to share it here without confidential data.
--
When all you have is a hammer, every problem looks like a nail.
Thank you in advance to everyone who takes the time to read me and help me find some workarounds.
I have an Excel file that works solely through forms.
Everything works relatively well, but I sometimes encounter "quirks," bugs that appear for no apparent reason. The code works, but from time to time, it enters debugging mode, and often all it takes is to move the yellow line back to the beginning of the sub for everything to work correctly again.
I want to specify that all my code sheets have the "option explicit" key and that the project is compiled, so presumably, there are no rogue variables wandering around.
My idea to try to understand these "quirks" would be to create a bug report module, looping through the active userforms and retrieving the values and states of each object. But since each userform is different, it can range from 3 objects to more than a hundred.
Is there a way to make this loop generic, regardless of the number of objects, their types (textbox, combobox, checkbox, optionbutton, etc.), and their names? A kind of code in this idea, but I can’t figure out how to write it.
For Each ufactif In thisproject For Each objet In ufactif If objet Like Label Then Next objet Worksheets("toto").Range("tata") = objet.Name Worksheets("toto").Range("tutu") = objet.Value Next objet Next ufactif Being a sales tool that has about a hundred sheets, twenty userforms, and just as many modules, it's impossible for me to share it here without confidential data.
--
When all you have is a hammer, every problem looks like a nail.
13 réponses
Hello,
an example of code to list the objects of multiple UserForms if there is no label with a single procedure
https://www.cjoint.com/c/LFljK6JB7ig
an example of code to list the objects of multiple UserForms if there is no label with a single procedure
https://www.cjoint.com/c/LFljK6JB7ig
Hello
An example to get the list of control names of a userform
https://www.cjoint.com/c/LFljRgDtwYB
Best regards
An example to get the list of control names of a userform
Private Sub btok_Click() Dim s As String Dim OObj s = "" For Each OObj In Me.Controls s = s & OObj.Name & vbLf Next OObj MsgBox s End Sub
https://www.cjoint.com/c/LFljRgDtwYB
Best regards
Hello ccm81 and thank you for your feedback,
your code is quite similar to that of f894009
you declare
same question as to f894009: not knowing where the bug comes from, do we need to anticipate the call of your example in every sub of each user form?
your code is quite similar to that of f894009
you declare
dim OObj: when you don't specify the As something, a variable is automatically declared as Variant, right? In your example, we could declare
dim OObj As MSForms.Control?
same question as to f894009: not knowing where the bug comes from, do we need to anticipate the call of your example in every sub of each user form?
yg_be
Posted messages
23437
Registration date
Status
Contributeur
Last intervention
Ambassadeur
1 588
hello,
maybe:
maybe:
Dim comp, ct As Control, s As String Debug.Print Now() For Each comp In ThisWorkbook.VBProject.VBComponents If comp.Type = 3 Then Debug.Print comp.Name For Each ct In comp.designer.Controls s = TypeName(ct) Select Case s: Case "Label": Case "TextBox", "CheckBox": Debug.Print ct.Name, ct.Value Case Else: Debug.Print ct.Name, s End Select Next ct End If Next comp
Hello yg_be, and thank you for your feedback.
If I understand correctly, your example analyzes the entire workbook, all the sheets, and all the user forms, right?
I've already seen
I also tried calling your procedure from a user form (I created a button with a call to the procedure on the click event), but it crashed on the line
If I understand correctly, your example analyzes the entire workbook, all the sheets, and all the user forms, right?
s = TypeName(ct)gives the type of the object (combobox, textbox, etc.), right?
I've already seen
Debug.Print(often in the codes you share, by the way), but I don't know how to use it, and I don't see anything on the screen when I step through the code; what does it actually do?
I also tried calling your procedure from a user form (I created a button with a call to the procedure on the click event), but it crashed on the line
For Each ct In comp.designer.Controlswith the message "object variable or block variable not set." However, when I put it in a subroutine triggered by F5, the loop runs correctly. If I want to use it when a bug occurs with user forms open, will it return the error message, or have I done it incorrectly?
variante:
Dim comp As UserForm, ct As Control, s As String Load UserForm1 Load UserForm2 Debug.Print Now() For Each comp In UserForms 'Debug.Print comp.Parent.Name For Each ct In comp.Controls s = TypeName(ct) Select Case s: Case "Label": Case "TextBox", "CheckBox": Debug.Print ct.Name, ct.Value Case Else: Debug.Print ct.Name, s End Select Next ct Next comp
This also allows you to have the name of the userform:
Dim comp As UserForm, ct As Control, s As String Debug.Print Now() For Each comp In UserForms For Each ct In comp.Controls s = TypeName(ct) Select Case s: Case "Label", "CommandButton": Case "TextBox", "CheckBox": Debug.Print ct.Parent.Name, ct.Name, ct.Value Case Else: Debug.Print ct.Parent.Name, ct.Name, s End Select Next ct Next comp
Indeed, your new code only deals with active user forms (and that's great)
it's
The goal is to retrieve the values in a bug report, and not knowing where or when a bug will appear, should I call your code in each sub of all user forms and all modules, or is there another method? I'm thinking maybe of a public sub declared at the startup of the file. (I tried writing
Edit: I'm not asking for clarification on ct.Parent.Name for you to modify your code; you've already taught me enough for me to manage that on my own ;)
it's
For Each comp In ThisWorkbook.VBProject.VBComponentsthat processes the entire workbook except for active user forms?
ct.Parent.NameThis command returns the "location" (I don't know how to say) where the object is: if the object is on the user form, it returns the name of the user form, but if the object is in a frame, then it returns the name of the frame, right?
The goal is to retrieve the values in a bug report, and not knowing where or when a bug will appear, should I call your code in each sub of all user forms and all modules, or is there another method? I'm thinking maybe of a public sub declared at the startup of the file. (I tried writing
on error goto rapport_de_bugin public just after the line option explicit, but that would have been too easy!)
Edit: I'm not asking for clarification on ct.Parent.Name for you to modify your code; you've already taught me enough for me to manage that on my own ;)
Hello and thank you three for your informative and extremely interesting responses
I will reply to each of you in the comments on your respective posts ;)
--
When you only have a hammer, all problems look like a nail.
I will reply to each of you in the comments on your respective posts ;)
--
When you only have a hammer, all problems look like a nail.
yg_be
Posted messages
23437
Registration date
Status
Contributeur
Last intervention
Ambassadeur
1 588
I'm not convinced that your approach (to try to understand these "whims") will be successful.
The most important thing is to obtain the type of error. It can be obtained via "on error".
You write "often all it takes is to move the yellow line to the beginning of the sub": have you simply tried pressing F8, and is that not enough?
IF it works when starting again at the beginning of the script, doesn't that mean that it's not the userform data that's causing the problem?
EDIT:
after an error (when you are in the code that handles an
The most important thing is to obtain the type of error. It can be obtained via "on error".
You write "often all it takes is to move the yellow line to the beginning of the sub": have you simply tried pressing F8, and is that not enough?
IF it works when starting again at the beginning of the script, doesn't that mean that it's not the userform data that's causing the problem?
EDIT:
after an error (when you are in the code that handles an
on error,
Err.Numberand
Err.Descriptiongive you the error number and message.
You wrote "often it's enough to move the yellow line to the beginning of the sub": so you tried simply pressing F8, and that wasn't enough? Yes, F8 repeats the error message and once out of frustration, not understanding where the problem came from, I moved to the beginning of the sub and it worked
Doesn't that mean that it's not the data (from the userforms) that is causing the problem? Yes, I think like you, but since when my salespeople have a bug, they are unable to say what they were doing and where they clicked when it happened, I thought that the bug report could at least resolve that, and if it also allowed me to understand these "quirks," it would be all beneficial
Some salespeople can make me crash the file on routines that have been running for 2 years, but they come into my office with the debugging window and are unable to tell me how they did it, and even I am completely unable to reproduce the problem (it happened again an hour ago on the userform where there is only a dropdown list to choose their name and one validate button to go to the next userform)
Doesn't that mean that it's not the data (from the userforms) that is causing the problem? Yes, I think like you, but since when my salespeople have a bug, they are unable to say what they were doing and where they clicked when it happened, I thought that the bug report could at least resolve that, and if it also allowed me to understand these "quirks," it would be all beneficial
Some salespeople can make me crash the file on routines that have been running for 2 years, but they come into my office with the debugging window and are unable to tell me how they did it, and even I am completely unable to reproduce the problem (it happened again an hour ago on the userform where there is only a dropdown list to choose their name and one validate button to go to the next userform)
Hello and sorry for the late reply, I had a very busy weekend.. I still had time to think about our exchanges
I don't necessarily know the number and the error message to be honest, and that's also why I went for a bug reporting system:
either the salespeople are with clients in the store, and if they come to my office with a bug, my priority is to do what it takes to "unstick" the script and ensure that the file runs until the quote is issued so that the sale doesn't fall through. In this case, I admit that I barely look at the error message, I'm more in "against the clock" mode..
or the salespeople are at the clients' homes and then I learn the next day "that they missed a signature because my software crashed" but with no indication of what they were doing, where they clicked, etc.
So although I completely agree with you that the report may not be enough to solve this "whim" problem, I still believe it could be useful for allowing me to collect information in case of issues.
Moreover, following the bug that my salesperson had on Saturday with a theoretically impossible to crash uf (a listbox and a button), I thought that rather than retrieving the values of the objects in a somewhat raw way, there might be more interest in getting a "click log"..? that is to say, populating a table with each click type "click1-userform1-listbox1-value"toto"" that would be written to a dedicated sheet of the workbook if an error is triggered
at least it would have the merit of reproducing exactly the situation of the problem?
VBA allows a lot of things in debugging: examining variables, for instance.
I don't know this aspect of VBA but indeed it seems to be an undeniably useful tool to master. At least I know how to step through code, use the spies to monitor variable values in real-time (debug.print too now that I will start applying it) but I'm eager to learn and improve in VBA.
I don't necessarily know the number and the error message to be honest, and that's also why I went for a bug reporting system:
either the salespeople are with clients in the store, and if they come to my office with a bug, my priority is to do what it takes to "unstick" the script and ensure that the file runs until the quote is issued so that the sale doesn't fall through. In this case, I admit that I barely look at the error message, I'm more in "against the clock" mode..
or the salespeople are at the clients' homes and then I learn the next day "that they missed a signature because my software crashed" but with no indication of what they were doing, where they clicked, etc.
So although I completely agree with you that the report may not be enough to solve this "whim" problem, I still believe it could be useful for allowing me to collect information in case of issues.
Moreover, following the bug that my salesperson had on Saturday with a theoretically impossible to crash uf (a listbox and a button), I thought that rather than retrieving the values of the objects in a somewhat raw way, there might be more interest in getting a "click log"..? that is to say, populating a table with each click type "click1-userform1-listbox1-value"toto"" that would be written to a dedicated sheet of the workbook if an error is triggered
at least it would have the merit of reproducing exactly the situation of the problem?
VBA allows a lot of things in debugging: examining variables, for instance.
I don't know this aspect of VBA but indeed it seems to be an undeniably useful tool to master. At least I know how to step through code, use the spies to monitor variable values in real-time (debug.print too now that I will start applying it) but I'm eager to learn and improve in VBA.
Hello to both of you,
Just to move things along
Is your error only in one Userform?
When you test things at home (I assume you do), you can remember the steps you took at the time of the error. Since you created this "Application," it should be two fingers in the nose
When you encounter the error, click on debug and hover your mouse over the variables on that line to see their content
before going back to the beginning of the procedure
Put a breakpoint on the line beneath the one where you have the error
go back to the beginning
restart and check the variables when the code execution stops
If it persists and causes you to lose signatures, you should still consider showing your file with non-confidential data. It's up to you.
Just to move things along
Is your error only in one Userform?
When you test things at home (I assume you do), you can remember the steps you took at the time of the error. Since you created this "Application," it should be two fingers in the nose
When you encounter the error, click on debug and hover your mouse over the variables on that line to see their content
before going back to the beginning of the procedure
Put a breakpoint on the line beneath the one where you have the error
go back to the beginning
restart and check the variables when the code execution stops
If it persists and causes you to lose signatures, you should still consider showing your file with non-confidential data. It's up to you.
Hello f894009
Your error is only in one Userform? No, they can crash the file anywhere and anytime: a uf with a listbox where you have to write your name (to retrieve the sales rep's name for the invoice edition) and the validate button that switches
When you do tests at home (I think you do), can you memorize the actions you took at the time of the error. Since it’s you who created this "Application", it should be two fingers in the nose. Yes, I personally test the new content as much as possible before making it available and as mentioned earlier, I indeed use the step-by-step and variable control tools with cursor passing and watchers to check that everything goes as I intended but apparently, it's wild people clicking all over the place.
When it comes to a bug due to a wrong instruction, I can spot it and fix it quickly.
In general, the "quirks" happen mostly during mail merge; sometimes it gets stuck when opening Word, sometimes when saving the Word as a PDF after mail merge, but there’s no consistency on the line that gets stuck, on the Word used, on the sheet in the workbook that feeds the mail merge, etc.
We should still consider showing your file with non-confidential data. It's up to you. You have no idea how much I would love to share my work and get constructive feedback on it... beyond the rates and confidential info, my file fetches several hundred photos (at least 600 in total) that dynamically illustrate the choices clicked in real-time, it chooses which Word to use from a twenty-file pool for the mail merge and therefore all paths are hard-coded in my program, and I admit that I struggle to see how to make the code neutral and usable by an external person, but God knows I’d love it to be possible!
Your error is only in one Userform? No, they can crash the file anywhere and anytime: a uf with a listbox where you have to write your name (to retrieve the sales rep's name for the invoice edition) and the validate button that switches
.enabled=trueon
_afterupdateof the listbox if the name matches the proposed list... (I've been using this routine for almost 4 years so it’s quite tested)
When you do tests at home (I think you do), can you memorize the actions you took at the time of the error. Since it’s you who created this "Application", it should be two fingers in the nose. Yes, I personally test the new content as much as possible before making it available and as mentioned earlier, I indeed use the step-by-step and variable control tools with cursor passing and watchers to check that everything goes as I intended but apparently, it's wild people clicking all over the place.
When it comes to a bug due to a wrong instruction, I can spot it and fix it quickly.
In general, the "quirks" happen mostly during mail merge; sometimes it gets stuck when opening Word, sometimes when saving the Word as a PDF after mail merge, but there’s no consistency on the line that gets stuck, on the Word used, on the sheet in the workbook that feeds the mail merge, etc.
We should still consider showing your file with non-confidential data. It's up to you. You have no idea how much I would love to share my work and get constructive feedback on it... beyond the rates and confidential info, my file fetches several hundred photos (at least 600 in total) that dynamically illustrate the choices clicked in real-time, it chooses which Word to use from a twenty-file pool for the mail merge and therefore all paths are hard-coded in my program, and I admit that I struggle to see how to make the code neutral and usable by an external person, but God knows I’d love it to be possible!
Hi,
Unless I'm mistaken, you never specified the number and the text of the error.
What does the line in question do?
Can you show the line or provide a screenshot?
Unless I'm mistaken, you never specified the number and the text of the error.
What does the line in question do?
Can you show the line or provide a screenshot?
re,
it's not necessarily crashing on the same line, that's my concern otherwise I would have looked into that direction. As mentioned above:
I don't necessarily know the number and the error message, to be honest, and that's also why I opted for a bug report system:
either the salespeople are with clients in the store, and if they come to my office with a bug, my priority is to do what’s necessary to "unstick" the script and ensure that the file runs until the quote is printed to prevent the sale from falling through. In this case, I admit that I barely look at the error message, I'm more in a "against the clock" mode..
or the salespeople are at the clients' homes and the next day I learn "that they missed a signature because of my software crashing" but with no indication of what they were doing, where they clicked, etc.
however, it took me 4 hours, but I think I’ve thoroughly checked my binder to allow for a confidential send, and (normally) I commented all the lines that contain file paths that wouldn’t work anywhere but at my place.
even though it's a bit borderline with the CCM charter, I would prefer to send it in a private message once I'm sure that the recipient lives far enough away from me and that they are not likely to step foot in my store.
I apologize for the approach, but I care about my job ;)
it's not necessarily crashing on the same line, that's my concern otherwise I would have looked into that direction. As mentioned above:
I don't necessarily know the number and the error message, to be honest, and that's also why I opted for a bug report system:
either the salespeople are with clients in the store, and if they come to my office with a bug, my priority is to do what’s necessary to "unstick" the script and ensure that the file runs until the quote is printed to prevent the sale from falling through. In this case, I admit that I barely look at the error message, I'm more in a "against the clock" mode..
or the salespeople are at the clients' homes and the next day I learn "that they missed a signature because of my software crashing" but with no indication of what they were doing, where they clicked, etc.
however, it took me 4 hours, but I think I’ve thoroughly checked my binder to allow for a confidential send, and (normally) I commented all the lines that contain file paths that wouldn’t work anywhere but at my place.
even though it's a bit borderline with the CCM charter, I would prefer to send it in a private message once I'm sure that the recipient lives far enough away from me and that they are not likely to step foot in my store.
I apologize for the approach, but I care about my job ;)
Re,
I'm sorry for the process, but I value my job
It goes without saying.
You say that the error appears from any Userform, but is it in a procedure used by all or one per Userform?
sure that the recipient lives far enough from my place
Use personal messaging and tell me where you're from, I'll do the same.
As for confidentiality, no worries on that side.
I'm sorry for the process, but I value my job
It goes without saying.
You say that the error appears from any Userform, but is it in a procedure used by all or one per Userform?
sure that the recipient lives far enough from my place
Use personal messaging and tell me where you're from, I'll do the same.
As for confidentiality, no worries on that side.
My salespeople are magicians who manage to uncover bugs literally anywhere, any uf, any procedure, but when it happens they are unable to explain which event/button/click it occurred on.
These are not recurring bugs; they still manage to work fairly smoothly (over 1200 quotes last year with my file), but I am never safe from a magic trick and an improbable bug on routines that have been tested over time.
Hence my idea to create a bug report in order to understand how they got there.
If you can't reproduce the problem, I don't really see the point, for now, of providing a file that may not even contain the "defect" of the original file.
Perhaps ask users to take a screenshot with the error message and then with the problematic part in the code?
An intermittent bug can also come from the environment, not from your code.
Perhaps ask users to take a screenshot with the error message and then with the problematic part in the code?
An intermittent bug can also come from the environment, not from your code.
This is the original file I sent; I removed all the prices, the logos, and commented out the paths for saving and searching for photos, that’s the only difference with the file my sales team uses.
What I'm also interested in (this wasn't planned) is to get a general opinion on my work.
A bug can come from the environment that’s a bit what I fear... Is there a way to check that?
What I'm also interested in (this wasn't planned) is to get a general opinion on my work.
A bug can come from the environment that’s a bit what I fear... Is there a way to check that?
Here is what I am currently focusing on:
in the module that serves as my General module (the one that groups procedures that can be called from several userforms):
And I plan to add this to each sub (it's going to be a lot of work..!) :
Does this seem coherent to you or am I off track?
in the module that serves as my General module (the one that groups procedures that can be called from several userforms):
Option Explicit Public z As Long Public TabJournal(500) Sub JournalDeClic(uf As UserForm) z = z + 1 Select Case TypeName(uf.ActiveControl) Case "Label", "CommandButton": TabJournal(z) = "Click " & z & " on: " & TypeName(uf) & ", object: " & TypeName(uf.ActiveControl) & ", name: " & uf.ActiveControl.Name Case "TextBox", "CheckBox", "OptionButton", "ComboBox": TabJournal(z) = "Click " & z & " on: " & TypeName(uf) & ", object: " & TypeName(uf.ActiveControl) & ", name: " & uf.ActiveControl.Name & ", value: " & uf.ActiveControl.Value Case Else End Select End Sub Sub BugReport() Dim x As Integer x = 1 Worksheets("Bug").Range("A1").Value = "Error no.: " & Err.Number & " : " & Err.Description Do Until TabJournal(x) = "" Worksheets("Bug").Range("A" & x + 1).Value = TabJournal(z) x = x + 1 Loop End Sub And I plan to add this to each sub (it's going to be a lot of work..!) :
Private Sub lbLoggin_Enter() On Error GoTo fatal Call JournalDeClic(ufLoggin) ' ' 'normal code ' ' Exit Sub fatal: Call BugReport End Sub
Does this seem coherent to you or am I off track?
Hello there
I am desperate, nothing is going the way I want
I use
+ while doing these tests, I realize that the on error prevents the debugging window from appearing. For a "minor" bug, like an inaccessible set focus, that's fine since it doesn't interfere with the rest of the program, but for a "major" bug, like trying to access a Word document that doesn't exist at the specified path, the program needs to stop because the rest of the program will not be able to execute, and especially the user needs to be informed of the impossibility to continue
Is there a way to differentiate between a bug that does not affect the continuation of the program and a bug that completely crashes the sequence of operations?
--
When you only have a hammer, every problem looks like a nail
I am desperate, nothing is going the way I want
I use
TypeName(uf.ActiveControl)to retrieve the name of the object in my "click log," but if the object is in a frame, for example, it returns the name of the frame instead of the name of the object, so I have no traceability of the clicks
+ while doing these tests, I realize that the on error prevents the debugging window from appearing. For a "minor" bug, like an inaccessible set focus, that's fine since it doesn't interfere with the rest of the program, but for a "major" bug, like trying to access a Word document that doesn't exist at the specified path, the program needs to stop because the rest of the program will not be able to execute, and especially the user needs to be informed of the impossibility to continue
Is there a way to differentiate between a bug that does not affect the continuation of the program and a bug that completely crashes the sequence of operations?
--
When you only have a hammer, every problem looks like a nail
I tried.. and I didn’t understand which direction you wanted to send me
by writing these 2 lines, it goes into rapportdebug which does its job well, but after that it returns to the error and the debug window appears
I tried resume next instead of resume: it works well on the set focus error that I created on a button with visible=false but on the error of the word that does not exist (which I wrote to symbolize an error preventing the code from continuing) there the next is useless which I understand but that doesn’t help me.. Unless I redo another on error goto that would call a sub with a message and the closing of the file? Is that possible?
by writing these 2 lines, it goes into rapportdebug which does its job well, but after that it returns to the error and the debug window appears
I tried resume next instead of resume: it works well on the set focus error that I created on a button with visible=false but on the error of the word that does not exist (which I wrote to symbolize an error preventing the code from continuing) there the next is useless which I understand but that doesn’t help me.. Unless I redo another on error goto that would call a sub with a message and the closing of the file? Is that possible?
Hello,
to look for a word that does not exist at the indicated path
test before it exists, for example:
Ok=Dir(paths & File)
If Ok<>"" then we continue, otherwise message and exit.
to look for a word that does not exist at the indicated path
test before it exists, for example:
Ok=Dir(paths & File)
If Ok<>"" then we continue, otherwise message and exit.
Hello f894009
Yes, the non-existent Word was just an example, I wasn't quite sure how to deliberately trigger an error to see if what I was writing was doing what I expected, so I changed the name of a Word.
Logically, in my file, these names are hardcoded, so that doesn't happen, but if the program encounters a bug with the same consequences, how do I differentiate it from a bug without consequences and how do I handle it (I haven't yet implemented yg_be's response)
I admit I'm a bit lost with the on error, I'm trying to research it but it's still very unclear, and as a result, I'm nitpicking
and especially I'm demoralized by this
Yes, the non-existent Word was just an example, I wasn't quite sure how to deliberately trigger an error to see if what I was writing was doing what I expected, so I changed the name of a Word.
Logically, in my file, these names are hardcoded, so that doesn't happen, but if the program encounters a bug with the same consequences, how do I differentiate it from a bug without consequences and how do I handle it (I haven't yet implemented yg_be's response)
I admit I'm a bit lost with the on error, I'm trying to research it but it's still very unclear, and as a result, I'm nitpicking
and especially I'm demoralized by this
TypeName(uf.ActiveControl)which does not return what I expect, and similarly, I can't find a solution.. it's just not my day!
Re,
differentiating between a harmless bug and how to handle it
Well, it's you who defines what to do next in the event of an error in the code.
If the error compromises the execution of the code to reach a "normal" result, you need to provide an exit that allows you to restart without recording anything while warning that there has been a major error or to continue while accepting some damage.
For example:
You need the name of the Frame to get the name of the Active control.
It's the same for Typename.
Given that in your application there are practically only frames, even frames within a frame, it won't be easy to sort out.
This, of course, in addition to the errors related to UF objects.
So far, I haven't encountered any VBA errors related to the code. For the editing part, I can't test.
I'll see if I can adapt to continue; otherwise, I'll destroy your file.
differentiating between a harmless bug and how to handle it
Well, it's you who defines what to do next in the event of an error in the code.
If the error compromises the execution of the code to reach a "normal" result, you need to provide an exit that allows you to restart without recording anything while warning that there has been a major error or to continue while accepting some damage.
For example:
n = UserForm1.Frame1.ActiveControl.Name
You need the name of the Frame to get the name of the Active control.
It's the same for Typename.
Given that in your application there are practically only frames, even frames within a frame, it won't be easy to sort out.
This, of course, in addition to the errors related to UF objects.
So far, I haven't encountered any VBA errors related to the code. For the editing part, I can't test.
I'll see if I can adapt to continue; otherwise, I'll destroy your file.
it's up to you to define what to do next in case of an error at the code level
depending on which sub or which module, knowing the degree of importance of the bug risk, I need to create 2 different subs and call either one that reports the bug without interrupting the program or the other that warns and closes the file, right?
it's not going to be easy to sort out
the simplest solution I've found so far is to add the name of the object as a parameter
This obviously in addition to the errors related to UF objects
didn't understand the sentence
I'll see if I can adapt to continue otherwise I'll destroy your file
Great, thank you very much for taking the time to look into it, keep me posted.
depending on which sub or which module, knowing the degree of importance of the bug risk, I need to create 2 different subs and call either one that reports the bug without interrupting the program or the other that warns and closes the file, right?
it's not going to be easy to sort out
the simplest solution I've found so far is to add the name of the object as a parameter
Sub JournalDeClic(uf As UserForm, Objet As String)
This obviously in addition to the errors related to UF objects
didn't understand the sentence
I'll see if I can adapt to continue otherwise I'll destroy your file
Great, thank you very much for taking the time to look into it, keep me posted.
Hello!
The bug report is in progress, all that's left is to wait and see what comes of it.
I want to thank f894009 again for taking the time to review my file, but he didn't find any bugs related to the code itself, if I understood correctly.
The goal now is to turn our attention to the environment issues that yg_be mentioned last week:
How are they detected? How are they addressed?
F894009 told me that my lines of code could be refreshed with more recent instructions that would improve execution times: could this be a factor affecting environmental problems?
Thank you in advance for any working leads you can provide me.
--
When you only have a hammer, all problems look like nails.
The bug report is in progress, all that's left is to wait and see what comes of it.
I want to thank f894009 again for taking the time to review my file, but he didn't find any bugs related to the code itself, if I understood correctly.
The goal now is to turn our attention to the environment issues that yg_be mentioned last week:
How are they detected? How are they addressed?
F894009 told me that my lines of code could be refreshed with more recent instructions that would improve execution times: could this be a factor affecting environmental problems?
Thank you in advance for any working leads you can provide me.
--
When you only have a hammer, all problems look like nails.
in the sub you declare but in the code you use declared variable Ctl and then we find Ctrl. We agree that this is not intentional but rather a typo?
To use your example, you need to call the procedure by providing the name of the uf you want to analyze, so not knowing where the bug comes from, do we need to plan the call in each sub of each uf?