Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Control with wierd value 1

Status
Not open for further replies.

ftook

Programmer
Dec 4, 2006
80
GB
I have a control on a form and perform calculations based upon input into the control, for some reason the control has a value of 13266, and whatever I enter into the control is ignored and this number is taken as its value, I cant see any difference between this control and another control on the form, I have even copied the other control, renamed it and still the same, I have also looked at underlying table, all seems ok.

Can anyone help please ?
 
How are ya ftook . . .

This is typical behavior of a [blue]calculated control[/blue]. Your problem is that the [blue]Control Source[/blue] of the control is set to an fixed expression . . .
Code:
[blue] = [b][i]expression[/i][/b][/blue]
. . . and thats all it cold ever be under the circumstances.

What you need to do is remove any text in the [blue]Control Source[/blue] then thru code write the expression to the control instead . . .
Code:
[blue]   Me!TextboxName = [b][i]expression[/i][/b][/blue]
. . . then you'll be able to overwrite as you've been trying.

[blue]Your Thoughts? . . .[/blue]

Calvin.gif
See Ya! . . . . . .
 
The control source is not set on the resulting control and the calculation is already set as a written expression via the code.

Any ideas ?
 
No, the control wouldnt accept input if locked
 
ftook . . .

Then your running code in some event thats replacing it!. Why would you want to replace a calculated value anyway?

Calvin.gif
See Ya! . . . . . .
 
it is not a calculated control, i perform calculations through code on the result and store in another control
 
ftook . . .

Delete and reinstantiate the control . . .

Calvin.gif
See Ya! . . . . . .
 
I have tried that, not worked, but the control is named width and in the code i refer to it as me.width, once i changed this to width99 it worked ok, seems funny cuz i have a control called height and this was all ok.

Thanks for your feedback and advise.

 
he he - if you look at TheAceman1's referencing style at the top, they use Me!TextboxName (with a bang), lot of developers like using dot, i e Me.TextboxName, which makes writing code a tiny bit faster, due to the control then popping up in the Intellisence (though, when you start typing Me!te then hit ctrl+space, the same effect is achieved). This makes it even more important to avoid using reserved words as names of controls or other objects, check out these two lists


You would have found that trying these two

?Me.Width
?Me!Width

in the immediate pane (ctrl+g) would deliver different results, as the dot reference, references the width property of the form, while the bang notation references a form control called Width (or a field in the forms recordsource with that name)

Same - if you use "Name" as name of a control, try the difference between

?Me.Name
?Me!Name

Roy-Vidar
 
ftook said:
[blue] . . . the control is named width and in the code i refer to it as me.width[/blue]
Although [blue]Width[/blue] is not a reserved word, it is a form property and and [blue]should not be used to name a control![/blue]

[blue]Height[/blue] on the other hand is not a form property but [blue]is a property of the header, Footer and Detail sections of a form[/blue] and should not be used to name a control for the same reason.

Finally in answer to the context of [blue]RoyVidar's[/blue] post:
Microsoft said:
[tt][blue]Use the ! and . (dot) operators in expressions
You use the ! and . (dot) operators in an identifier to indicate the type of item that immediately follows.

The ! operator indicates that what follows is a user-defined item (an element of a collection). For example, use the ! operator to refer to an open form, an open report, or a control on an open form or report.

Identifier Refers to
Forms![Orders] The open Orders form
Reports![Invoice] The open Invoice report
Forms![Orders]![OrderID] The OrderID control on the open Orders form

The . (dot) operator usually indicates that what follows is an item defined by Microsoft Access. For example, use the . (dot) operator to refer to a property of a form, report, or control.

Note You can also use the . (dot) operator to refer to a field value in an SQL statement, a Visual Basic for Applications method, or a collection. For example, the identifier Forms![Orders].Controls refers to the Controls collection of the Orders form. However, because the Controls collection is the default collection for forms and reports, it's usually not necessary to refer to it explicitly.[/blue][/tt]
[blue]For learned programmers it shouldn't matter what method is used![/blue] [thumbsup2]

[blue]Your Thoughts? . . .[/blue]

Calvin.gif
See Ya! . . . . . .
 
My thoughts? Well, I use neither dot nor bang notation when referencing controls in VBA, so I wouldn't know what to say ;-)

Microsoft isn't consistant, heres the example from the help topic for the Parent property (to name one), where dot is used to reference form controls.

Example
The following example uses the Parent property to examine the parent of the Speedy Label label control, the Speedy check box control, and the ShipVia option group. To run this example, open the Orders form in the Northwind sample database then run this code.

[tt]Public Sub ShowParent()

Dim frm As Form
Dim ctl As Control

Set frm = Forms!Orders
Set ctl = frm.[Speedy Label]

' Returns name of control attached to label.
MsgBox "The parent control is " & ctl.Parent.Name
Set ctl = frm.Speedy

' Returns name of control containing control.
MsgBox "The parent control is " & ctl.Parent.Name
Set ctl = frm.ShipVia

' Returns name of form containing option group control.
MsgBox "The parent control is " & ctl.Parent.Name

End Sub[/tt]

"Bolding" by me.

My point is "The downsides of using the dot? You may run into trouble if your control or field has the same name as one of the built-in properties of a form -- so don't do that!"


Dot vs bang should be mostly interchangeable in form coding, except for the property/control clash, and when you change recordsource dynamically (in code), where the dot notation might/will fail. Since the dot notation is evaluated at compile time, any non existing controls, will give compile errors.

Personally, I find it somewhat peculiar that Microsoft uses dot notation in the documentation without any warning about under which circumstances it will fail.

Sometimes you'll find Access apps with a lot of invisible controls stuck into a corner - which is a workaround used by "dotters" with too much dislike of the bang notation ;-)

On the reserved words - I was under the impression that the "More information" paragraph from the link of of reserved words in Access 2002 and Access 2003, indicated that functions, methods and properties of existing (and added objects/libraries) also fall into the reserved word category?

"Because it is not practical to provide a list of all reserved words, such as built-in function names or Microsoft Access user-defined names, please check your product documentation for additional reserved words. Note that if you set a reference to a type library, an object library, or an ActiveX control, that library's reserved words are also reserved words in your database. For example, if you add an ActiveX control to a form, a reference is set, and the names of the objects, methods, and properties of that control become reserved words in your database"

Also, what most developers would recommend, is using a naming convention where one renames every control that one reference through code or expressions, so that
1 - there's no clash with existing properties, at least if you're a "dotter" ;-)
2 - the control name differs from the name of the controlsource (the name of the field it's bound to)

This will usually mean prefixing text controls with txt, combos with cbo, command buttons cmd, listboxes lst...

Roy-Vidar
 
Conversations like this are left for the experts, I read them and fully appreciate (and take on board) the information imparted by the experts. This type of forum is new to me and I am in awe as to the knowledge held and passed on by its members.

What I am saying is that "keep up the good work" the forum has become an invaluable source of knowledge sharing that saves so much head scratching and also allows avenues of coding that may otherwise not be attempted.

Many thanks to you all.
 

Have a Star, ftook... me thinks you deserve a thanking for thinking to thank the thinkers.

Surfing the 'net' is one thing. Serving (others) with their brain waves is another (as Ace and Roy routinely do).

Just a thought...

Don [smile]

[green]Tis far easier to keep your duck in a row if you just have the one.[/green]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top