Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsVB SyntaxEnterprise DevelopmentDatabase AccessControlsCOMWin APICrystal ReportDeploymentGeneralGeneral 2
Related Topics
VB.NET / ASP.NETMS SQL ServerMS AccessOther Database ProductsMore Topics ...

VB Forum / COM / April 2005



Tip: Looking for answers? Try searching our database.

passing VB.Controls to compiled DLL Problem

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
R Avery - 21 Apr 2005 22:46 GMT
I come from a VBA environment where I am used to doing things like
abstracting away UI elements like moving items in a listbox up or down
with items... into some DLL that i make with a ListOrderer class which
you use by passing references to the listbox control and all of the
up/down buttons.

Now that I am writing some things in VB6, I found that I cannot simply
just export my VBA (designed in Excel) forms and import them into VB6
Forms.  Why do these form objects appear in the "Designers" portion of
the TreeView rather than the "Forms" portion.

So, I started designing a VB6 form, and hoped that it could use the
same ListOrderer class that I used in the VBA form.  Unfortunately, VB6
does not use MSForms controls, but rather uses VB controls.  VB
controls have different methods, properties, etc!  That is one problem
I don't understand, but I can get over it.  It means i'd have to design
a new ListOrderer for VB6.  So I did that.  Unfortunately, it gave me
an error saying that "A property or method call cannot include a
reference to a private object, either as an argument or as a return
value" when I made the arguments to the ListOrderer class VB.Listbox
and VB.Button.  So i simply changed them to Object and hoped it would
work.

However, it still doesn't work because when i try to use the
ListOrderer (which is compiled in a separate DLL) in the Standard EXE
Form i am trying to make, it gives me this error again.  I looked
online for some descriptions of the error and I found the following
MSDN link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vb
condatatypesusedinpropertiesmethods.asp


According to this, I can't pass VB controls to DLLs PERIOD!  What is
that?  How do you guys abstract UI functionality like drag and drop
items between two listboxes or automatically sync'ing a form's controls
(with set tag properties) to a custom object's properties?

Any help in response to any of my questions above would be greatly
appreciated.  Thanks.
Ken Halter - 21 Apr 2005 23:24 GMT
>I come from a VBA environment where I am used to doing things like
> abstracting away UI elements like moving items in a listbox up or down
[quoted text clipped - 6 lines]
> Forms.  Why do these form objects appear in the "Designers" portion of
> the TreeView rather than the "Forms" portion.

They're not VB forms? <g>...

> So, I started designing a VB6 form, and hoped that it could use the
> same ListOrderer class that I used in the VBA form.  Unfortunately, VB6
> does not use MSForms controls, but rather uses VB controls.  VB
> controls have different methods, properties, etc!  That is one problem
> I don't understand, but I can get over it.  It means i'd have to design

Different controls, written by different authors, have different
property/method names and functionality.
btw... Not only does VB not use MSForms controls, but MSForms controls are
illegal to distribute so it's good that VB doesn't use them. You can add
them to the toolbox but why bother. They're complete junk as far as compiled
VB apps are concerned (ignoring the "not legal" part).

> a new ListOrderer for VB6.  So I did that.  Unfortunately, it gave me
> an error saying that "A property or method call cannot include a
[quoted text clipped - 15 lines]
> items between two listboxes or automatically sync'ing a form's controls
> (with set tag properties) to a custom object's properties?

Not exactly sure what you mean there... but, I have a set of classes I add
to projects when needed. These classes are Private, which means I can do
anything I want. Only the classes I want are added to the project so there's
no "bloat", plus, if I want, I can customize the class without worrying
about Binary Compatibility (like you will if you create a DLL)

When you're dealing with Public classes, you have to deal with COM rules.
COM has (and all languages that support it) no idea what a VB.ListBox is so
it's not allowed at all. There are tons of things you can't do because
they'd be going against COM rules.

The error message you got there isn't the end of the story. See:

PRB: Passing ActiveX Control to Component Gives "Type Mismatch" Error
Message
http://support.microsoft.com/default.aspx?scid=kb;en-us;190210

If you have to add this kind of thing to a DLL, you can use As Object in
this case... doesn't work well in all cases though (per KB article)
'==============Form Code
Option Explicit

Private Sub Form_Load()
  Dim o As Class1

  With List1
     .AddItem "Item 1"
     .AddItem "Item 2"
     .AddItem "Item 3"
     .AddItem "Item 4"
  End With

  Set o = New Class1
  Call o.ShowItems(List1)

End Sub
'==============Class1 Code
Option Explicit

Public Sub ShowItems(LB As Object)
  Dim i As Integer
  For i = 0 To LB.ListCount - 1
     Debug.Print LB.List(i)
  Next
End Sub
'==============

Signature

Ken Halter - MS-MVP-VB - http://www.vbsight.com
Sign up now to help keep VB support alive - http://classicvb.org/petition
Please keep all discussions in the groups..

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.