Search results

First...this kind of code needs to be in both the AfterUpdate event, as shown...and in the OnCurrent event. Next...what kind of Form is this...Single, Continuous or Datasheet? Lastly...if, as the last line of the above, you add Msgbox Me.txtRootCause what results do you get? Linq ;0)>

theDBguy's advice will separate the Controls so that they can be moved individually...but the phenomena you're experiencing, moving from one box to another, isn't caused by the size of the screens...but rather by differences in the resolutions of the two screens. Have a look at this post by...

There's no way to convert a .accde file back to a .accdb file...that's why it's important to save your .accdb file after converting it. WE really need to see all relevant code, as theDBguy said. The point of converting the file to a .accde file is to 'lock down' the database so that end users...

Haven't had my first cup of java, yet, but I thought in referring to a Control on a Form, in a Control Source for another Control on the Form, you simply use the Control name surround by brackets: =DLookUp("UserAccess","tblEmployees","strEmpName = '" & [txtUsername] & "'") Linq ;0)>

Per the original post Going through the song-and-dance of hiding everything seems like an overly complicated way to accomplish this. Wouldn't simply saving/distributing the file as an accde file be the simplest way? Linq ;0)>

Here's a Function that can be used to expand a given Control by using the Double-Click event for the Control. You can create a Function to do the zooming, select the desired Controls to be included, then assign the Function to the DoubleClick event of all of the Controls: In a Standard Module...

Presumably UserName is Text...then "[UserName]=" & Me.TxtUsername.Value) should be "[UserName]='" & Me.TxtUsername.Value & "'") Linq ;0)>

To expand on that just a little bit... Set up your Combobox using the Wizard and include the Fields you need, from Left-to-Right. Here's a general example of assigning values from a Combobox to Textboxes. If, in the Row Source for the Combobox they appear, reading left-to-right, as Field1 |...

In doing this kind of thing...once you set AllowEdits to True, it'll stay True for that Record...even if you explicitly try to set AllowEdits to False, again, until you exit the Record. The only reasonable way to do this is, to me, using the single Form, is to Lock all Controls except the...

A Subform is a Control on the Main Form...so if LockBoundControls does what it says...i.e. locks all Bound Controls...the Subform is Locked and you could neither enter data nor Spell Check it. You'd need to lock all Controls except the Subform Control to do this...unless I'm misinterpreting...

This kind of code is fine when only validating a single Control. But when validating multiple Controls, as you're doing...to avoid the problem you're seeing you have to do each validating, adding an Exit Sub command...i.e. Private Sub Form_BeforeUpdate(Cancel As Integer) If...

The same applies to a Datasheet View Form...which is likely to be the situation (assuming it's not in Continuous View) since your talking about coloring 'rows.' In that case you have to use the same advice, i.e. Conditional Formatting, but either use it to change the color of one Control...

Or even simpler..you can add a small Label to the right of the Textbox that says "kg." It has the added advantage of reminding the user of the unit of measure that is to be entered. Linq ;0)>

I don't know why this has persisted, even among knowledgeable people such as yourself, but it has. As I said, I'm pretty sure I've even seen it in some of Allen Browne's hacks. I really have to wonder if it performed differently in the early versions of Access. I've always ignored it when seeing...

Can't make him do the backstroke, either...no matter how hard you try! :banghead: Linq ;0)>

I see this advice, from time to time...and believe I even saw it in a hack by Allen Browne years ago...but in today's VBA it's inappropriate for this task. The Form_BeforeUpdate event is, indeed, the event to use, as it fire at the last instant before the Record is saved, thus dramatically...

I agree with Colin...the important thing, here, is to figure out why the corruption keeps happening repeatedly! Is the app divided into a Front End/Back End configuration...with the data on the Back End and a copy of the Front End on every user's PC? And you haven't said...what version of...

I didn't know you were a politician, Uncle Gizmo!:D Linq ;0)>

Just Call each button from the 4th Button: Private Sub Button4_Click() Call Button1_Click Call Button2_Click Call Button3_Click End Sub using your actual button names, of course. Welcome to Access World! Linq ;0)>

Important question: Is this being done in a one-off database...i.e. with only a single user...or is it in a multi-user environment? This is important in order to prevent multiple records have the same InvNo! Linq ;0)>