Cannot Position a TreeView Control

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am using a TreeView ActiveX control (mxcomctl.ocx Version 6.0.88.62; Win
2K, Access 2000) and have successfully implemented all necessary
functionality except for one annoying issue: Any attempt to set the .Top or
..Left properties is ignored when the form loads. The control defaults to the
upper left of its form regardless of how or when I set the location. Though I
can work around this with minor changes to the layout, it is at some point
bound become a major issue.

Is there anyone who knows how to solve this?
 
I use the Current() event.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
 
Graham:

Perhaps I didn't make myself clear. The content of the TreeView is correct
and it is updated properly under all conditions.

The issue is its physical location on the form. When the form is opened, the
control repositions itself to the upper left of the form. It doesn't matter
when I set the .top and/or .left properties or what values I assign them (I
am using .top=0.25 and .left=0.125)

Any suggestions?
 
Well, I've "not answered" a previous post of yours about treeeview controls,
and no-body else seems able to help on this, so here's all I can offer:

I haven't got the exact combination of Access, O/S and OCX version as you
have, but I've never had a problem positioning a treeview control, in A2K
under WinXP Pro, A2002 under WinXP Home, or A97 under WinME. I can position
the control(s) by any usual method in form design mode, and it(they) also
respond(s) to setting .Top and .Left properties via VBA code (eg. in
Form_Load). Once again, you've got me stumped!

Perhaps you've simply got some weird glitch with the particular instance of
the control on your form. Have you tried deleting it (copy any associated
code into the clipboard, or elsewhere, so you don't loose it all and have to
start from scratch) and placing a new treeview control onto your form?
That's about all I can suggest - it's what I'd try ;-)

Rob

PS. I saw your follow-up to your previous treeview problem, saying that an
updated .ocx file fixed it. Checked and found I already had the later
version - perhaps that's why I've never seen the problem.
 
You made yourself clear enough pal, but I at least thought you'd be using
Twips, which is what the control expects!

Since you're not, multiply centimetre values by 567 to arrive at Twips.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
---------------------------
 
Hi Graham (and NoVAFolk),

I think maybe we're slightly at cross-purposes here, but it may be
fortuitous! You seem to be responding to the same post to which I
responded, but my newsreader shows your post as a follow-up to mine (not
shown in the thread below).

The OP ("NoVAFolk"), in his original post, did not refer to trying to set
position via code, he only said that his control remained anchored at
top-left of his form, with values of 0.25 and 0.125 (no units quoted). In
form design mode (which I assumed the OP was referring to originally) it's
perfectly acceptable to enter a value in cm (or inches, if that's Window's
default units). If the OP was trying to set the position via code, rather
than in form design mode, then setting values as he quoted would result in
the controls being set at top-left of his form.

Problem hopefully solved, and mystery (at least for me) dispelled ;-)

Except for why NoVAFolk is positioning his controls via code, rather than in
form design mode!

Rob
 
Rob,

I wasn't responding to your post; yours just happened to be the last one I
read.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
---------------------------
 
Rob, Graham:

Thank you for your interest in the problem. It remains unresolved but an
acceptable workaround has been to redesign the form to accomodate the
behavior. Oh well ...

FYI: the design properties are in inches; positioning in code is in the
corresponding Twips.
 
Sorry for not getting back to you earlier; I've just been very busy.

There have been many posts of a similar vein to yours, but few of the MVPs
have experienced the same issue. Although it's been known to happen, I can
find no KB articles about it, and the accepted solution is to explicitly set
its position in the form's Load() event. I would tend to resolve the issue
by using the form's Current event, or the Tab control's Change() event (as
appropriate).

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
---------------------------
 
Back
Top