Topic: Total newby to the swamp... VB block insertion

[Bryco]

 Unload Me, isn't included in the error handling, is this a problem?

[Jeff_M]

  is this a problem?

Yes.....but in the infamous words of Bob W. "I was waiting for..." akdrafter to notice.  :whistle:

[Kerry]

heheheheheheeehe
 

[Bob Wahr]

...but keep in mind when you do that that no matter what seems to be happening in your drawing, you can't do what you're doing.

Could you clarify this, Bob? It appears to me that it does do what he's doing....for now. Granted, ACAD no longer has a color property but it does still accept it, I'm sure for legacy purposes. But how long before they remove that backward compatibility?
Maybe what you were saying is that, although it seems to be working as desired now, don't be a bit surprised when it stops and pukes on your new tennis shoes? Which brings us back to that Error_Trap......

so... there should be no worry about redefining the layer properties.

I guess that's why I always do it the way I do. I work with a number of different firms and I must make sure to use whatever each one has already done. If I'm adding the layer, then I make it the same for each one, but I never alter their existing layers.
One thing to be careful of, though. While you CAN use the ADD method without worry of one already being there in the Layers collection, doing the same thing with 'most' other collections will generate an error. It's another one of those "you gotta know when to use it" things that comes with experience.

I was just, in my usual roundabout semi-serious way, pointing out that the color property no longer officially exists and although it still works for layers in 2006, it may not in 2007 (haven't tested) or future releases.  I believe that, like the Add method, I have run across a few things that will toss an error if you try to use Color instead of TrueColor.  I for one would prefer that Adesk add the Color property back in officially for everything.  If there are 256 colors available in ACAD, let me use them.

[akdrafter]

for the err_han.....like this?

Code: [Select]

err_han:
Debug.Print Err.Number & Err.Description
Unload Me
  Exit Sub
End Sub
As far as the color/true color property you guys speak of, is there a "prefered" way of defining this...

"Dim blkColor As Integer"

"objLayer.color = blkColor"

Bob,

Why is the "booLayer" dimensioned as true/false (boolean)?

Back to my lines and circles...

[akdrafter]

Slight change of subject....but got to thinking of color when the "True Color" came up....here is some true color for ya.

Yeah baby. Nuttin like gettin bent by one of these.

[Bob Wahr]

I guess as it keeps coming up and rightly so when it does, we might as well start hitting on the error trapping.  When an error happens, there are a few things that you can do with it. 

The first that I'll mention is to ignore it.  This is normally a really, REALLY bad thing to do.  As you can see with Jeff's use on On Error Resume Next followed by some in line handling, there are times that it is fine to do.  Of course, in his example, you aren't actually ignoring the error, you are just telling the program to ignore it for long enough for you to fix it.

Secondly, you can cut and run.  That is what you are doing with your error handling now.  If there is an error of any sort, stop the program where it is and get out immediately.  This works sufficiently for most problems. But...

Thirdly, as you can see with Jeff's layer checking example, there are times that you want to use an error.  There are also times that errors can occur under certain circumstances that won't really affect your program in a bad way and can be ignored or errors that can be fixed when they occur and the program can continue.

What I generally use for my error handling is something that I picked up from Randall

Code: [Select]

Exit_Here:
  Exit Sub
err_han:
  Select Case err.Number
    Case -14663844 'arbitrary number I typed in for an example this error can be ignored
      err.clear
      Resume Next ' Resumes the program on the next line of code after the one that generated the error
    Case -18284765 'This is an error that we know how to fix
      'We do what needs to be done to fix it here
      err.Clear
      Resume ' Note: this will resume the program on the same line that broke it before
    Case Else 'If any other error occurs, get the duck outta Fodge
      debug.print err.number & " " & err.description
      Msgbox "It Broke",vbcritical, "Boom"
      err.clear
      goto exit_here
  End Select

AK, Good catch (the boolayer (hell, the trout too for that matter)) I started to do something different than I ended up doing with your code, then changed course but didn't entirely clean up after myself.

[Bob Wahr]

What kind of fish do you need the sidearm for?

[akdrafter]

My wife said that she wants me home after every fishing trip...which I do a lot...uhhh...fish and come home for that matter. hahahahah... I draw just about every day, but so far have ever only drawn that piece of hardware once and only because what I was aiming at was 15' from me and wasn't expecting my company. Althought we were both fishing at the time. I think I caught more that day than it did. And not for nuttin... but some of our fish up here are actually shot before you can get them into the boat. Halibut... Baby got back... Anyway......

Ok, So I am sitting here trying to think of what kind of errors one might run into when using this particular type of app. I think I need to write them down and see how it affects what the app is doing, if I can resolve the error and continue or if the error makes the rest of the code unusable.

The "-#######" error numbers....are those error codes and if so are they documented somewhere?

Thanks for the input Bob.

[Bob Wahr]

The numbers I used were randomly typed.  I have seen some really sparse documentation on error numbers but never anything super comprehensive.  What I generally do is start with

Code: [Select]

Exit_Here:
  Exit Sub
err_han:
  Select Case err.Number
    Case Else 'If any other error occurs, get the duck outta Fodge
      debug.print err.number & " " & err.description
      Msgbox "It Broke",vbcritical, "Boom"
      err.clear
      goto exit_here
  End Select
When errors occur, I figure out what is causing the error and what I can/should do with it.

[akdrafter]

So, basically I need to test and test to make sure it works and make it fail if I can, then I will know how to deal with those errors.

[Bob Wahr]

No matter how extensively you test and how many different things you try, when you release it for use, someone will break it immediately.  The best you can hope for in that case is that the error can be reproduced so that it can be fixed.

[Jeff_M]

My $0.02......I agree with Bob on how to find the errors you need to trap. Yes, you basically need to try to break it to be able to fix it.

One thing I know will fail within 5 minutes of a user testing it, they will initiate a transparent command, such as Pan, when you are requesting the insertion point....an unhandled error is raised so you, not so nicely, just dump them out......they go "What da .....?!!!! TTTTIIIIIIMMMMMMM, what'd ya do? I can't zoom or pan or nuttin' I think you broke my Autocad!!! WHAHHHHH!!!" Well, you get the idea.....

Look around for a modified GetPoint....I think Bryco has posted one here that was a derivitive of an RR function that I have somewhere.

[Bob Wahr]

akdrafter,

Moving on without you somewhat, I've done a little bit of rearranging on your Userform_Initialize Sub.  First I will post it as you have it with my comments.  Then I will post how I would do it.

Code: [Select]

Private Sub UserForm_Initialize()
Dim arrType1() As String
Dim arrType2() As String
Dim arrType3() As String
Dim arrTmp As Variant
Dim strTmp As String
Dim fFile As Integer
Dim I As Long

ReDim arrType1(0 To 999)
ReDim arrType2(0 To 999)
ReDim arrType3(0 To 999)
'Redimming three arrays to 999 just to make space uses memory unneccesarily
'It will also cause you program to crash if there are 1001 or more blocks
'Why not just redim the array as needed when needed
fFile = FreeFile


'Do you really need all three lists filled out at the beginning?
'If the user is picking a block from List 1, the time and memory used to
'populate all 3 arrays is 2/3 wasted, I would move these down to the click subs
'**** Type 1
Open MyPath & "_Type1.txt" For Input As #fFile
'Need to skip the first 4 lines
For I = 0 To 4
    Line Input #fFile, strTmp
Next
I = 0
While strTmp <> "" 'this will stop it once it encounters a blank line
    arrType1(I) = strTmp
    I = 1 + I
    Line Input #fFile, strTmp
Wend
Close #fFile
ReDim Preserve arrType1(0 To I - 1)
ReDim arrName1(0 To I - 1, 0 To 4)
For I = 0 To UBound(arrType1)
    arrTmp = Split(arrType1(I), ",")
    arrName1(I, 0) = arrTmp(0)
    arrName1(I, 1) = arrTmp(1)
    arrName1(I, 2) = arrTmp(2)
    arrName1(I, 3) = arrTmp(3)
    arrName1(I, 4) = arrTmp(4)
Next
'End of Type 1

'**** Type 2
Open MyPath & "_Type2.txt" For Input As #fFile
'Need to skip the first 4 lines
For I = 0 To 4
    Line Input #fFile, strTmp
Next
I = 0
While strTmp <> "" 'this will stop it once it encounters a blank line
    arrType2(I) = strTmp
    I = 1 + I
    Line Input #fFile, strTmp
Wend
Close #fFile
ReDim Preserve arrType2(0 To I - 1)
ReDim arrName2(0 To I - 1, 0 To 4)
For I = 0 To UBound(arrType2)
    arrTmp = Split(arrType2(I), ",")
    arrName2(I, 0) = arrTmp(0)
    arrName2(I, 1) = arrTmp(1)
    arrName2(I, 2) = arrTmp(2)
    arrName2(I, 3) = arrTmp(3)
    arrName2(I, 4) = arrTmp(4)
Next
'End of Type 2

'**** Type 3
Open MyPath & "_Type3.txt" For Input As #fFile
'Need to skip the first 4 lines
For I = 0 To 4
    Line Input #fFile, strTmp
Next
I = 0
While strTmp <> "" 'this will stop it once it encounters a blank line
    arrType2(I) = strTmp
    I = 1 + I
    Line Input #fFile, strTmp
Wend
Close #fFile
ReDim Preserve arrType2(0 To I - 1)
ReDim arrName3(0 To I - 1, 0 To 4)
For I = 0 To UBound(arrType2)
    arrTmp = Split(arrType2(I), ",")
    arrName3(I, 0) = arrTmp(0)
    arrName3(I, 1) = arrTmp(1)
    arrName3(I, 2) = arrTmp(2)
    arrName3(I, 3) = arrTmp(3)
    arrName3(I, 4) = arrTmp(4)
Next
'End of Type 3
''Provide a default button, usually the first in the list
OptionButton1.Value = True
End Sub

Private Sub ListBox1_Click()
Dim I As Integer
I = ListBox1.ListIndex
blkName = ListBox1.List(I, 1)
blkLayer = ListBox1.List(I, 2)
blkColor = ListBox1.List(I, 3)
blkLType = ListBox1.List(I, 4)
End Sub


Private Sub OptionButton1_Click()
'If this Sub is running, OptionButton1 was clicked so this will always
'be true, there's no reason for the IfThen check
If OptionButton1.Value = True Then
    ListBox1.Clear
    ListBox1.List = arrName1
    ListBox1.ListIndex = 0
End If
End Sub

Private Sub OptionButton2_Click()
If OptionButton2.Value = True Then
    ListBox1.Clear
    ListBox1.List = arrName2
    ListBox1.ListIndex = 0
End If
End Sub

Private Sub OptionButton3_Click()
If OptionButton3.Value = True Then
    ListBox1.Clear
    ListBox1.List = arrName3
    ListBox1.ListIndex = 0
End If
End Sub

Code: [Select]

Private Sub UserForm_Initialize()
  OptionButton1.Value = True
End Sub

Private Sub ListBox1_Click()
Dim I As Integer
I = ListBox1.ListIndex
blkName = ListBox1.List(I, 1)
blkLayer = ListBox1.List(I, 2)
blkColor = ListBox1.List(I, 3)
blkLType = ListBox1.List(I, 4)
End Sub

Private Sub OptionButton1_Click()
Dim arrType1() As String
Dim arrTmp As Variant
Dim strTmp As String
Dim fFile As Integer
Dim I As Integer

fFile = FreeFile

  Open MyPath & "_Type1.txt" For Input As fFile
  For I = 0 To 4
    Line Input #fFile, strTmp
  Next
  I = 0
  While strTmp <> ""
    ReDim Preserve arrType1(0 To I)
    arrType1(I) = strTmp
    I = 1 + I
    Line Input #fFile, strTmp
  Wend
  Close fFile
  ReDim arrName1(0 To UBound(arrType1), 0 To 4)
  'Redim this to ubound(arrtype1) and they will always match without a doubt
  'I - 1 should be the same always but there's no chance that ubound(arrtype1) won't be ubound(arrtype1)
  'make sense?
  For I = 0 To UBound(arrType1)
    arrTmp = Split(arrType1(I), ",")
    arrName1(I, 0) = arrTmp(0)
    arrName1(I, 1) = arrTmp(1)
    arrName1(I, 2) = arrTmp(2)
    arrName1(I, 3) = arrTmp(3)
    arrName1(I, 4) = arrTmp(4)
  Next
  ListBox1.Clear
  ListBox1.List = arrName1
  ListBox1.ListIndex = 0
End Sub

Private Sub OptionButton2_Click()
Dim arrType2() As String
Dim arrTmp As Variant
Dim strTmp As String
Dim fFile As Integer
Dim I As Integer

fFile = FreeFile

  Open MyPath & "_Type2.txt" For Input As fFile
  For I = 0 To 4
    Line Input #fFile, strTmp
  Next
  I = 0
  While strTmp <> ""
    ReDim Preserve arrType2(0 To I)
    arrType2(I) = strTmp
    I = 1 + I
    Line Input #fFile, strTmp
  Wend
  Close fFile
  ReDim arrName2(0 To UBound(arrType2), 0 To 4)
  For I = 0 To UBound(arrType2)
    arrTmp = Split(arrType2(I), ",")
    arrName2(I, 0) = arrTmp(0)
    arrName2(I, 1) = arrTmp(1)
    arrName2(I, 2) = arrTmp(2)
    arrName2(I, 3) = arrTmp(3)
    arrName2(I, 4) = arrTmp(4)
  Next
  ListBox1.Clear
  ListBox1.List = arrName2
  ListBox1.ListIndex = 0
End Sub

Private Sub OptionButton3_Click()
Dim arrType3() As String
Dim arrTmp As Variant
Dim strTmp As String
Dim fFile As Integer
Dim I As Integer

fFile = FreeFile

  Open MyPath & "_Type3.txt" For Input As fFile
  For I = 0 To 4
    Line Input #fFile, strTmp
  Next
  I = 0
  While strTmp <> ""
    ReDim Preserve arrType3(0 To I)
    arrType3(I) = strTmp
    I = 1 + I
    Line Input #fFile, strTmp
  Wend
  Close fFile
  ReDim arrName3(0 To UBound(arrType3), 0 To 4)
  For I = 0 To UBound(arrType3)
    arrTmp = Split(arrType3(I), ",")
    arrName3(I, 0) = arrTmp(0)
    arrName3(I, 1) = arrTmp(1)
    arrName3(I, 2) = arrTmp(2)
    arrName3(I, 3) = arrTmp(3)
    arrName3(I, 4) = arrTmp(4)
  Next
  ListBox1.Clear
  ListBox1.List = arrName3
  ListBox1.ListIndex = 0
End Sub
As you can see, there's really very little that I changed in your code, mostly what I did was rearrange it.  Do you understand why and how I did what I did?

[akdrafter]

Bob,

To answer your question... To some extent I do understand what you are saying.

As far as memory goes. The only memory used is when the user selects a type. So, if the user only selects type1, then only type1 will be stored in memory. However, if the user selects type1, type2 and type3 "OptionButton"s before they finally make up their mind, then all 3 would be stored in memory which would be the equivalent of having those types preloaded into memory at the begining of the app.

When we start the app we simply tell it that "OptionButton1" has been clicked(True) so that the list box is populated.

The line "I = 0 To 4" ("I" being an integer enabled of going into the billions of places and being a whole number only "Long") is simply telling the app to not read the first four lines of the text file and to start at line #5.

Then after setting the "read" of the text file to start at the correct line....Line 5, we now start a "while" there is no blank space(the end of the text file) we are going to start taking each line of the text file and converting it into a string...."strTmp". The line "I = 1 + I" keeps moving down each line of the text file until a blank space is reached... "While strTmp <> """

So, now that we have our "strTmp" filled with the contents of the text file we are ready to move on to the separating of the pertinent items within that text file.

Now here is where I get fuzzy. I am not sure what the difference is in "arrType#" and "arrName#". I think......in Jeff's version of the code the app would Dim the "arrType#" to set it to a string. Then, ReDim the "arrType#" to store 1,000 places in memory. But, what you are doing is telling the app that the values in "arrName#" are always going to be the same as those in "arrType#" so there is no need to ReDim "arrType#".

The rest of the code I understand is separating the contents of the array into columns for later use by the insertion function.

So in a nutshell I believe what you have done is to... "Do only what is needed when it is needed and simplify things"... Oh... and there is more than one way to skin the cat.