R
Ronald Dodge
Is there an Access version of the OnTime Method that Excel has?
T
TC
If you told us what that method does, we might be able to answer 
TC
TC
R
Ronald Dodge
The OnTime method in Excel is setup as
Application.OnTime <Earliest Time it starts>,<Name of Procedure it will
attempt to execute>,[<Latest Time it starts>],[True/False]
as the syntax above indicates, it will attempt to start the
procedure/function starting at the earliest time as set in the first
argument. However, is there's already stuff being executed, it will wait
until there is nothing being execute, which then it will execute the code
with one exception to this rule. If the latest time has been set as that's
an optional argument, and the time has already came and left before the
procedure could be fired up, this will not fire up the code.
The last argument is to either set the firing up of the procedure, which is
the default with the True setting, or to cancel the firing up of the code
with the False setting, which has been proven to be useful in few cases in
Excel. I attempted to use this same code in Access, but I got the run time
error code of "50290" of which the help page just comes up as a grey blank
page.
The main thing, I have a situation in Access that I'm attempting to do with
the Mouse Down event, but cause Access itself has code that's ran after the
MouseDown Event is ran, regardless what the button/shift variables are
changed to, I need to have some way to run my code immediately after Access
runs it's code that runs after the MouseDown Event has taken place.
Though I hate programming like this cause a lot of things can happen, if not
used with care, but what other choice do I have other than to just live with
it? I guess I could create a mock listbox, but that would take up way too
much time to program. It's already bad enough that I'm currently working on
creating various item function methods just to manipulate string lists, some
of which are already coded and completed.
Application.OnTime <Earliest Time it starts>,<Name of Procedure it will
attempt to execute>,[<Latest Time it starts>],[True/False]
as the syntax above indicates, it will attempt to start the
procedure/function starting at the earliest time as set in the first
argument. However, is there's already stuff being executed, it will wait
until there is nothing being execute, which then it will execute the code
with one exception to this rule. If the latest time has been set as that's
an optional argument, and the time has already came and left before the
procedure could be fired up, this will not fire up the code.
The last argument is to either set the firing up of the procedure, which is
the default with the True setting, or to cancel the firing up of the code
with the False setting, which has been proven to be useful in few cases in
Excel. I attempted to use this same code in Access, but I got the run time
error code of "50290" of which the help page just comes up as a grey blank
page.
The main thing, I have a situation in Access that I'm attempting to do with
the Mouse Down event, but cause Access itself has code that's ran after the
MouseDown Event is ran, regardless what the button/shift variables are
changed to, I need to have some way to run my code immediately after Access
runs it's code that runs after the MouseDown Event has taken place.
Though I hate programming like this cause a lot of things can happen, if not
used with care, but what other choice do I have other than to just live with
it? I guess I could create a mock listbox, but that would take up way too
much time to program. It's already bad enough that I'm currently working on
creating various item function methods just to manipulate string lists, some
of which are already coded and completed.
R
Ronald Dodge
Hrmmm, I just had a thought process. Just as I was looking into see about
randomizing numbers as I have dealt with that before, it mentioned about
using the Randomize statement to be based on the Timer function. I also
knew about the form level having an "OnTimer" property, of which as I was
looking at that, I was thinking, is there some way of how to get a piece of
code to be triggered in under 1 full second, and it led me to the
TimerInterval property on the form.
Now the thing about it, I don't want to have this code executing so much to
the point that it slows down the form, so what I had thought about is in
addition to using the OnTimer Event of the form, I would have the
TimerInterval property set to some real high number, which then when the
MouseDown Event is triggered on the list box, have this TimerInterval number
set to something like 50 (5 hundredth of a second), then have the On Timer
Event set this interval back to some real high number. This is just a
thought process at this time, but something I may just as well try out to
see if it resolves my issue.
randomizing numbers as I have dealt with that before, it mentioned about
using the Randomize statement to be based on the Timer function. I also
knew about the form level having an "OnTimer" property, of which as I was
looking at that, I was thinking, is there some way of how to get a piece of
code to be triggered in under 1 full second, and it led me to the
TimerInterval property on the form.
Now the thing about it, I don't want to have this code executing so much to
the point that it slows down the form, so what I had thought about is in
addition to using the OnTimer Event of the form, I would have the
TimerInterval property set to some real high number, which then when the
MouseDown Event is triggered on the list box, have this TimerInterval number
set to something like 50 (5 hundredth of a second), then have the On Timer
Event set this interval back to some real high number. This is just a
thought process at this time, but something I may just as well try out to
see if it resolves my issue.
T
TC
Ronald, you have mentioned so many different things that my head is
beginning to hurt!
Is this true: you want to run some code immediately after Access has fired a
mousedown event?
If so, please explain briefly, why do you need to do that? What are you
trying to achieve, results-wise?
TC
beginning to hurt!
Is this true: you want to run some code immediately after Access has fired a
mousedown event?
If so, please explain briefly, why do you need to do that? What are you
trying to achieve, results-wise?
TC
R
Ronald Dodge
Issue at hand, I'm attempting to create a Drag and Drop type feature on a
listbox and the company owners aren't willing to pay out money for
purchasing additional tools, so I have to program it myself. Whenever I
click the mouse button, it runs the code that's in the MouseDown Event, then
Access runs it's own Selection Program immediately after the code in the
MouseDown Event has ran. Given that, it prevents any of my selection from
taking hold (my selection takes place, but then Access negates it by running
it's own program). Changing the Button code and/or the Shift code within
the MouseDown Event doesn't help matters either. This is why I wanted to
have a code type deal that runs *AFTER* Access' Selection Program runs on
the listbox.
Creating work arounds via code is nothing new to me as I had to do several
including how Data Validation is done in Access specifically cause the way
it's done in Access by default is not mouse user friendly in certain cases
(thus my forms can't be bound for this reason), had to create my own work
around in Excel cause of the limitations of external link formulae not to
mention I had to code as far as when which files gets opened and closed
during the time the information gets processed due to *FIXED* RAM usage
limitations regardless how much RAM is on the system (only up to 80MB [160MB
for XP] of RAM can be used without Excel crashing). These are just a few of
the many issues that I have had to create work arounds for.
listbox and the company owners aren't willing to pay out money for
purchasing additional tools, so I have to program it myself. Whenever I
click the mouse button, it runs the code that's in the MouseDown Event, then
Access runs it's own Selection Program immediately after the code in the
MouseDown Event has ran. Given that, it prevents any of my selection from
taking hold (my selection takes place, but then Access negates it by running
it's own program). Changing the Button code and/or the Shift code within
the MouseDown Event doesn't help matters either. This is why I wanted to
have a code type deal that runs *AFTER* Access' Selection Program runs on
the listbox.
Creating work arounds via code is nothing new to me as I had to do several
including how Data Validation is done in Access specifically cause the way
it's done in Access by default is not mouse user friendly in certain cases
(thus my forms can't be bound for this reason), had to create my own work
around in Excel cause of the limitations of external link formulae not to
mention I had to code as far as when which files gets opened and closed
during the time the information gets processed due to *FIXED* RAM usage
limitations regardless how much RAM is on the system (only up to 80MB [160MB
for XP] of RAM can be used without Excel crashing). These are just a few of
the many issues that I have had to create work arounds for.
T
TC
(snip)
Ronald, you're telling me what does not work, but you still aren't telling
me how you want it to work, or what you actually want to make happen!
When you click the mouse on an entry in a listbox or combo box, Access will
run the code in the MouseDown event, and then, select the entry that you
clicked the mouse on.
What do you want to happen *instead*?
TC
Ronald, you're telling me what does not work, but you still aren't telling
me how you want it to work, or what you actually want to make happen!
When you click the mouse on an entry in a listbox or combo box, Access will
run the code in the MouseDown event, and then, select the entry that you
clicked the mouse on.
What do you want to happen *instead*?
TC
R
Ronald Dodge
As I been saying, I want to have my own code control the selection and
moving of items process based on users actions, not Access. Using the
OnTimer Event and TimerInterval property did do what it was expected,
however, I seemed to have opened another can of worms.
Now, for the main issue that I found doing so using both VBA debugging tools
as well as my own debugging methodology, At least with multi-extended
selection mode since that is the mode that I'm wanting to work with. The
Selected Property doesn't seem to work as it was meant to. Here's what I
mean:
If the code assigns the value of 0 or False, it doesn't change the state of
the item. If the item is selected, it stays selected, and if it's not
selected, it stays unselected, unlike the documentation saying that
assigning 0 would deselect it.
Just the opposite is true when assigning the value of -1 or True to the
Selected property of the item. If the item is selected and it gets the
value of -1, it goes to unselected, and if it's unselected and it gets the
value of -1, it goes to selected.
This above is what's taking place while the listbox has the focus unlike
what the documented help page on Selected Property in AC02, SP2, VBA Help
page shows.
I have also done some preliminary testings on the ItemsSelected and it's
count just returns 0 regardless if items are *ACTUALLY* selected or not,
while the mouse events are taking place and even within my code that runs
directly after the Access Selection program takes place. Before my code
does anything to any of the item's Selected Property, every single Selected
Property is 0, which means I will have to fully learn the behavior of the
listbox and the Access Selection program completely, which then control it.
However, that also means, once this bug does get fixed, my code is gonna
have to be changed again. Thankfully though, since I have all of the
associated code in a single class module, that will need to be changed after
the bug correction, I will only have to change it in one place.
moving of items process based on users actions, not Access. Using the
OnTimer Event and TimerInterval property did do what it was expected,
however, I seemed to have opened another can of worms.
Now, for the main issue that I found doing so using both VBA debugging tools
as well as my own debugging methodology, At least with multi-extended
selection mode since that is the mode that I'm wanting to work with. The
Selected Property doesn't seem to work as it was meant to. Here's what I
mean:
If the code assigns the value of 0 or False, it doesn't change the state of
the item. If the item is selected, it stays selected, and if it's not
selected, it stays unselected, unlike the documentation saying that
assigning 0 would deselect it.
Just the opposite is true when assigning the value of -1 or True to the
Selected property of the item. If the item is selected and it gets the
value of -1, it goes to unselected, and if it's unselected and it gets the
value of -1, it goes to selected.
This above is what's taking place while the listbox has the focus unlike
what the documented help page on Selected Property in AC02, SP2, VBA Help
page shows.
I have also done some preliminary testings on the ItemsSelected and it's
count just returns 0 regardless if items are *ACTUALLY* selected or not,
while the mouse events are taking place and even within my code that runs
directly after the Access Selection program takes place. Before my code
does anything to any of the item's Selected Property, every single Selected
Property is 0, which means I will have to fully learn the behavior of the
listbox and the Access Selection program completely, which then control it.
However, that also means, once this bug does get fixed, my code is gonna
have to be changed again. Thankfully though, since I have all of the
associated code in a single class module, that will need to be changed after
the bug correction, I will only have to change it in one place.
T
TC
Ronald, I think that you will not get much help unless you can keep things
short, stick to a single question until it is answered, & give a few lines
of example code.
Good luck
TC
short, stick to a single question until it is answered, & give a few lines
of example code.
Good luck
TC
R
Ronald Dodge
At this point, I now consider my Drag and Drop feature, at least the first
version of it complete. Despite the fact there are a couple of issues with
it, one of the 2, I'm not even sure what's causing it as it doesn't occur
every time, but rather only on rare occassions, and I have tried from so
many different angles to conquer it, but had no success, so all I will do at
this time is document that one, and the second one, I am considering it as a
Microsoft Access Bug as I have posted in the Form Coding newsgroup with the
steps to recreate the unexpected behavior problem. That issue will also be
documented.
Set aside from the couple of minor issues, most users shouldn't run into
very much, but may run into thus one reason for the documentation, I have
created a way for the user to drag and drop a mutliple selection type deal
within a listbox to be done either via keyboard and/or mouse. This is
rather basic initially and I do have other things planned to be added to
this feature, but that will have to wait 'til a later time as I have to
continue on with my overall development, as I work in my development phases.
version of it complete. Despite the fact there are a couple of issues with
it, one of the 2, I'm not even sure what's causing it as it doesn't occur
every time, but rather only on rare occassions, and I have tried from so
many different angles to conquer it, but had no success, so all I will do at
this time is document that one, and the second one, I am considering it as a
Microsoft Access Bug as I have posted in the Form Coding newsgroup with the
steps to recreate the unexpected behavior problem. That issue will also be
documented.
Set aside from the couple of minor issues, most users shouldn't run into
very much, but may run into thus one reason for the documentation, I have
created a way for the user to drag and drop a mutliple selection type deal
within a listbox to be done either via keyboard and/or mouse. This is
rather basic initially and I do have other things planned to be added to
this feature, but that will have to wait 'til a later time as I have to
continue on with my overall development, as I work in my development phases.