Re: Problem with .properties("...")

Tech-Archive recommends: Fix windows errors by optimizing your registry



"Steve Richfie1d" <Steve@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3lt95dF146mnmU1@xxxxxxxxxxxxxx
> Bob,
>
>> "Steve Richfie1d" <Steve@xxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:3lsvguF14ck8aU1@xxxxxxxxxxxxxx
>>
>>> XlateControlProperty Frm, Frm.Properties("Caption")
>>>
>>> This logic worked GREAT in Access 97, but seems to be falling on its
>>> face in VB5.
>>>
>>> Any ideas what is going haywire here?
>>
>> VB and VBA are not the same especially when it comes to forms and
>> controls. VB controls don't support a Propeties collection like that.
>
> But, when I highlight "Properties" in the statement above, VB brings
> up the DAO page on Properties just like I was in Access!

sounds like whatever you are doing is guessing and finding the first
"Properties" reference it can find. The DAO object may have that but the VB
Form object does not.

> I think that you are saying that there are Access Form and Control
> Properties that do NOT carry over to VB,

Sort of. The VBA forms engine, which is what Access uses, is completely
different than the VB forms engine. They have a lot of identical
finctionality, properties and methods but they are very distinct objects and
what works in one will not work in the other.

> and then there are DAO
> Properties that DO carry over to VB.

When VB references DAO it is using the same DAO object that you'd be using
from VBA in Access so it's not that anything "carries over" but rather that
you are talking to the same thing.

> Working with an object variable
> where VB doesn't know what the object is until execution time, I get
> the nastygram because it is NOT a DAO Property. Right?

Not sure I follow that. If you are declaring variables "as object" or "as
variant" then VB can't catch problems at compile time and will raise errors
at runtime. The error you describe is not DAO related though; DAO is one
thing, the VBA forms are another and the VB forms are a third.

> This is going to TRASH much of by otherwise simplistic code to switch
> between languages on-the-fly. There is a list box on the main form
> where if you select a different language, everything changes
> languages on all forms, etc. This is accomplished by going through
> all of the relevant properties of all of the forms - something that
> will be MUCH more difficult without the VB Properties property.

Maybe... in VB you probably want to look at something like

dim c as control
for each c in Me.Controls
If TypeOf C Is Label Then
c.caption="new value"
elseif typeof c is TextBox then
...
end if
next

or maybe a Select case using the TypeName(c) function... there are probably
other alternatives but since I don't really know exactly what properties you
are trying to change it's hard to say what the best approach might be.

> Note that it is easy to get the VALUE of a VB property - the challenge
> is getting that property as an object that can be passed around,
> modified, etc.

I can't say I've ever wanted to get the value as an object; probably because
since VB doesn't work that way so I don't think about the problem that way.
You can pass the controls around "As Obejct" or "As Control" and then work
with the properties and it may be that it's a bit more code than in VBA but
ya gotta do what ya gotta do! <g>

Perhaps you can write a class that accepts a control and exposes a
"Properties" collection that translates things for you to keep much of your
existing VBA code. OTOH, twisting a VBA-style solution into a VB container
may be harder to work with in the long run than simply rewriting the code in
a more VB-like style now.

--
Reply to the group so all can participate
VB.Net: "Fool me once..."

.



Relevant Pages

  • Re: DataGrid not showing programmatic changes
    ... It's not that DAO requires controls. ... the Data control or the DataEnvironment. ... simultaneous connection to a particular database ie each table or internal ... connection string to change. ...
    (microsoft.public.vb.general.discussion)
  • Re: DataGrid not showing programmatic changes
    ... so even DAO still requires controls to be put on a form. ... the main reasons I like the DataEnvironment, is like a publicly declared data ... simultaneous connection to a particular database ie each table or internal ... I don't have to specifically load the DBGRID32.OCX control eithe,r so ...
    (microsoft.public.vb.general.discussion)
  • Re: Get rid of options on File Menus
    ... Even apps which have even more customizable menus than Word ... can't control that menu. ... so I doubt any of the rest of the Office programs are going to. ... > Word VBA can control menu/toolbar visibility, but I doubt they added any ...
    (microsoft.public.mac.office)
  • Re: Circular dependencies between modules
    ... since a control can be passed as control or as value, ... > Public Sub SetData ... > I get a syntax error on the call statement in frmA! ... > features of the VBA language. ...
    (microsoft.public.access.formscoding)
  • Re: Access ListBox / ComboBox
    ... I'm a basicly a VB developper not VBA but i talk to few of my friends ... Look like that ComboBox or listbox from VBA is not using ... three or four different kinds of control sets, ... in vba 2 columns of data in a list/combo (i dont care as long it's ...
    (microsoft.public.office.developer.vba)