• WSDottie

    WSDottie

    @wsdottie

    Viewing 15 replies - 1 through 15 (of 58 total)
    Author
    Replies
    • in reply to: Current directory of database (A2K SR1) #607196

      Application.CurrentProject.Path will give the full path to your database
      Application.CurrentProject.FullName will give the full path including the filename of the .mdb file
      CurDir() will give the path to the default database folder as set on Tools –> Options –> General within Access

    • in reply to: filtering combo boxes (access 2k) #606894

      In the query behind the Cities combobox add a column for the State with a criteria that the State would equal the value of the States combobox. So the criteria would look something like this for the State field: Forms!frmCityStateSelect!cboState. Then in the after_update event for the State combobox you would requery the City combobox: Me!cboCity.Requery

    • in reply to: Fuzzy Fonts for Office Help (Office 2000) #604321

      Thanks very much! The Help file is legible again thanks to you. Following the Help topic you pointed me to, I set the Internet options, Accessibility, to “ignore font sizes specified on Web pages.” This affects the way Web pages appear too, but so far so good.

    • Hi Sue,

      It is possible that there is a “broken” reference to a library on one of the machines. On the machine that is giving you grief, go into the VB editor in Access and choose Tools –> references from the menu. If any of the checked references have a MISSING next to their name, you will have to fix it. Sometimes the paths to the referenced libraries vary from one machine to the next. Look at the references on the “good” machine too and see what file they actually point to (as you highlight each reference it shows the location at the bottom of the dialog box). This should help you find the same file on the troubled machine and reset the reference. It even happens sometimes that the references look to be good, show no “MISSING” ones, yet unchecking and rechecking them does some magical fix that lets them function properly again; always worth a try.

    • in reply to: Sign-on Logging (Best Practices) (VB6) #601877

      Hi Mike,
      Yes, that is the way QueryUnload is supposed to work. It has an UnloadMode parameter that you can check to see why the whether the form is about to be unloaded: due to code, the user clicking the X (control box), Windows shutting down, or the Task Manager End Task. You can set the Cancel parameter to True to prevent unloading if the mode is not the graceful exit you want. I’m just not sure if Citrix shutting the application down on a timeout will be treated the same way as End Task or Windows shutdown.

    • in reply to: Sign-on Logging (Best Practices) (VB6) #601789

      Mike, Have you tried putting the logout code in the QueryUnload event? That event will run even if the App is closing because of Windows shutting down, so maybe it will run if the reason for closing is a Citrix timeout.

    • in reply to: SQL query – search for null field (Access 2K SR-1) #600969

      SELECT * FROM tblTable WHERE fieldname IS NULL

    • in reply to: Unsuccessful FOR NEXT loop (97) #600649

      Can you use the TypeName function here?
      For each ctl…..
      If TypeName(ctl) = “ComboBox” then….

    • It is pretty odd! The shortcut runs OSA.EXE the Office Startup Application. There is some info at: http://support.microsoft.com/default.aspx?…b;en-us;Q165071 They say it initializes automation and code that is shared by the Office applications so that the applications start faster. Maybe there is some quirk in there that makes it bypass the global macros.

    • Hi Allen, You can add and remove references through code by using the AddFromCode and Remove methods of the References collection. In Access Help Index look for the topic “References Collection”; it gives coding examples. But if the references are needed for the project that you are going to distribute as an MDE wouldn’t they need to be toggled on at the time you build the MDE? I probably am not understanding what you want to. Each Reference also has a property named Builtin that is True if it is needed for Access to function properly, so you’ll need to always keep those set. Here’s some code you can try just to see what references are currently set, whether they are built-in, and if any are broken.
      Dim refx As Reference
      For Each refx In Application.References
      MsgBox refx.Name & “: ” & refx.FullPath & vbCrLf & _
      “Major : ” & refx.Major & ” Minor: ” & refx.Minor & vbCrLf _
      & “Builtin: ” & refx.BuiltIn & ” Kind: ” & refx.Kind

      If refx.IsBroken Then
      MsgBox refx.Name & ” is broken!”
      End If

      Next refx

    • in reply to: Copied DB remembers old path; gives error (2000) #599862

      We had a similar problem in which on some workstations the user was prompted to enter a password for the machine on which the shortcut was created; your problem might have the same root cause which is that the UNC path is embedded in the .lnk shortcut file and instead of resolving to the local relative path as it appears when you look at shortcut properties it resolves to the UNC path. In our case we were using C:microsoft…msaccess.exe…. in front of the path to the mdb file. On some machines it read C: as the originating workstation’s network name thus causing the prompt for password. This led us to find the following Knowledge Base articles and related links. It has something to do with which version of shell32.dll the user has. I believe in one of the articles it mentions that you can open the .lnk file in Notepad and see the full embedded path.
      http://support.microsoft.com/default.aspx?…b;en-us;Q150215 and http://support.microsoft.com/search/previe…b;en-us;Q158682

    • in reply to: Delete Query Syntax Error (VB6, SQL Server 2K) #599847

      Mike, I think what you want is DELETE FROM, omitting the *.

    • in reply to: Creating & Using a Public variable (1) #599598

      Roger,
      Sorry, I just realized I had some of the syntax wrong in what I just posted. I have been doing more VB than Access/VBA and was mixing things up a bit! In Access when you are referring to another form by name you have to use Forms! in front of the name, e.g. Forms!frmApple.XYZ, the Forms collection will only contain forms that are currently loaded, even if not visible. Probably some of the other people in this forum will have better ideas on which is preferable in this situation: a global variable in a module, or a public form-level variable in a form that stays loaded. Sorry for the error.

    • in reply to: Creating & Using a Public variable (1) #599589

      Including the Dim statement inside the apple_click procedure makes it local to that procedure only. Since you need XYZ to be available throughout the application once the user sets its value, you can either declare XYZ as a Public variable in a separate module (making it global) or declare it as a Public variable within your form and keep the form loaded (but not visible) at all times. Public variables on a form need to be declared in the General Declarations section rather than within a Sub and will need to be prefixed with the form’s name when referenced from another form. e.g. txtValue.text = frmApple.XYZ. Using the form to hold the variable (rather than a global in a separate module) allows you to limit where and how the value of the public variable gets changed.

    • in reply to: Control Buttons don’t work (Access 97) #598129

      Sometimes even though your event procedures are correctly named to match the name of your control and its event, a disconnect somehow occurs. For your btnViewAmendments command button, if you look at the events tab of its properties window, does it show that there is code for the Click event or not? If not, you just have to click next to the event name in the property list as if you were going to enter new code and that should hook it back up correctly.

    Viewing 15 replies - 1 through 15 (of 58 total)