Results 1 to 11 of 11
  1. #1
    Join Date
    Jul 2002
    Location
    Island of Dots
    Posts
    316

    Unanswered: KeyCode and Lightweight forms

    I am updating a database to use lightweight forms to try and make them load more quickly. On some of my forms I currently have this Sub behind the Form_KeyDown event:

    Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If KeyCode = 27 Then KeyCode = 0
    End Sub

    This simply disables the Escape key. How can I replicate this functionality using just a function that I can call directly from the new lightweight forms?

  2. #2
    Join Date
    Jun 2003
    Location
    Belgium
    Posts
    133

    Re: KeyCode and Lightweight forms

    What's the use of creating a function when your code is only one line and probably will never be changed?
    Why don't you just use the same line of code in your new forms?

    Originally posted by bcass
    I am updating a database to use lightweight forms to try and make them load more quickly. On some of my forms I currently have this Sub behind the Form_KeyDown event:

    Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If KeyCode = 27 Then KeyCode = 0
    End Sub

    This simply disables the Escape key. How can I replicate this functionality using just a function that I can call directly from the new lightweight forms?

  3. #3
    Join Date
    Jul 2002
    Location
    Island of Dots
    Posts
    316
    As I said in my original post, I am trying to make all my forms lightweight, that is, I will be removing all code from them, deleting their modules, and using function calls within the forms events.

  4. #4
    Join Date
    Jun 2003
    Location
    Belgium
    Posts
    133
    Originally posted by bcass
    As I said in my original post, I am trying to make all my forms lightweight, that is, I will be removing all code from them, deleting their modules, and using function calls within the forms events.
    I see your point : you want to replace 1 line of coding (as it is now) by 1 line of other coding (that will be calling a function)....
    What's the profit?
    Since there is no such built-in function, you'll have to create it yourselve in a module, that on its turn will add "weight" to your database.
    I agree you should keep the forms lightweight but don't push it to far! Using some coloured objects in a form will slow down the opening of the form more than that one line of coding.
    If you want to fasten up opening, try to make forms that are unbound with not too much objects in it.
    As this is not always possible, try to live with the fact that Access is a good program but always will need some time to load its forms and reports...

  5. #5
    Join Date
    Jul 2002
    Location
    Island of Dots
    Posts
    316
    I was under the impression that simply having a module behind a form would slow it down, even if that module had no code in it, which is why I am trying to eliminate all form modules (and replace them with functions). However, I keep hitting stumbling blocks, like the one I initially outlined, so I may restritict the lightweight forms approach. The extended developement time just doesn't justify the marginal speed increase.

  6. #6
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Well, there is an advantage to writing a function. If he wants to change the functionality or disable it (for debugging, say) he would only have to change the function, and not search through every form that might be calling it. What if he decides later that he wants a dialog box to prompt the user to confirm disabling the escape key?

    I don't think it's necessarily a bad idea to write a function for this admittedly small piece of code.

    blindman

  7. #7
    Join Date
    Jul 2002
    Location
    Island of Dots
    Posts
    316
    Thats pretty much what I've been trying to do with all my code - removing multiple instances of the same routines. I was going down the 'make everything into a function' route, but it was starting to become very messy. For example, I found I couldn't use the Me keyword in fuctions to refer to controls. So I ended up having to declare the full path for every control, eg - Forms!frmDataEntry!txtPostCode. Is there someway to assign Me with the 'Forms!frmDataEntry' bit first?

  8. #8
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Your functions shouldn't refer to specific controls or fields if they are to work across multiple forms. Keep them generic, and if you can't then keep them in your form modules.
    You can pass field values to them as parameters and your form module can modify specific controls based on the results returned, though this would appear to be unnecessary for the Form_KeyDown example you have given.

    You can also refer to the active form, most likely the calling form, by using this syntax:

    Screen.ActiveForm.[Method]

    I have a template database I use for rapid application development with a module called Global_Form_Control where I store lots of subroutines, some of them only 1 line long. I have template forms which already have vb modules to use this code, and I can develop quite complex database applications very quickly.

    blindman

  9. #9
    Join Date
    Jul 2002
    Location
    Island of Dots
    Posts
    316
    Sounds a bit more advanced than my current development environment. Thanks for the info.

  10. #10
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    taking stuff out of form-modules might make the form "lighter" but risks to make your whole application "heavier" - the first time you call a routine in a global module the whole module loads into memory (making first use slower than an equivalent "heavy" form because you are probably loading stuff belonging to other forms) and then the module stays in memory until you quit the application (making second+ use faster, it's true). you can achieve a similar result by hiding a speed-critical form instead of closing it.

    how many form-load milliseconds can you save by taking 5000 lines of form code and converting it to 50 lines of function calls? probably you lose more than those few milliseconds by having to use Forms!thisForm.thatControl syntax instead of the faster Me!thatControl

    (and to answer one of the questions below: NO, Me! only works in a form module).

    placing code in form or global modules is not a decision based on speed but on maintainability. stuff that is used by several forms should be global. standard "library" stuff that you use in several applications should be global. stuff that belongs to one form should be in that form's module.

    enough of philosophy: here's the answer to the original question:

    Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If KeyCode = 27 Then KeyCode = 0
    End Sub

    becomes

    Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    KeyCode = killEsc(KeyCode)
    End Sub

    Public Function killEsc(KeyCode as integer) as integer
    If KeyCode = 27 Then
    killEsc = 0
    else
    killEsc = KeyCode
    endif
    end function

    ...it's not pretty!

    izy

  11. #11
    Join Date
    Jul 2002
    Location
    Island of Dots
    Posts
    316
    What your saying rings ture, but that wasn't made terribly clear in an article I read on Microsofts site regarding lightweight forms. I am indeed hiding rather than closing the more frequently used forms anyway so I suspect that the speed increase would have been negligible by fully implementing a fully lightwieght approach. Thank God I found out now before I went ahead and changed all my code...

    Oh, and thanks for the solution!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •