BBS: Inland Empire Archive
Date: 10-26-92 (10:26) Number: 343
From: MICHAEL MALLEY Refer#: NONE
To: ALL Recvd: NO
Subj: VB/DOS Bugs/Fixes 2/ Conf: (2) Quik_Bas
>>> Continued from previous message
<F4>, <Alt>+<Up>, and <Alt>+<Down> are the keystrokes needed to
close and open the list manually. The secret is checking for them
in the KeyUp event. The keys are passed to the control prior to a
KeyDown event, the control absorbs these keystrokes because they
have special meanings, and no KeyDown event ever occurs. However,
a KeyUp event *DOES* occur for these key strokes.
In each of the command button's click events, include List1.REFRESH
as the first line, or Dummy = DOEVENTS() (I'll explain this one
later). This allows for <Alt>+<Hotkey> selection of a command
button.
This solution will cover all but the following combinations of
events:
The user opens the list
Clicks and holds an item with the mouse.
With the mouse button still down, selects another item with the
arrow keys on the keyboard
Finally release the mouse button.
Or:
The user selects an item with the keyboard.
The user closes the list by clicking the combo box's down arrow.
I realize that these two scenarios are really far fetched, as I
can't think of any reason that anyone would want to do these steps;
I really tried, but I'll be darned if I could figure out a way to
trap these two [Grin].
5. Displaying a form that has not been previously loaded will cause
bleed through if a combo box's list is about to be shown.
Explanation:
Let's assume that you are doing some type of data verification in
the LostFocus event of an object with a Text property. The user
types some illegal text in a text box, and takes the mouse and
clicks on the down arrow of a combo box. During the the
verification routines, you display a message with MSGBOX. If MSGBOX
and the area of the screen where the combo box's list will be
displayed overlap, then the underlying screen will show through the
overlapped portion. I have had a variation on this, where the list
is displayed, but MSGBOX's form can be moved behind the list!
Solution:
There are two possibilities here. One is to wait and do data
verification prior to saving whatever work was done.
The other is to write your own code and form for dealing with the
user. When your program is run, load the form as part of your
start up code. This is preferred anyway since you can manipulate
the form's colors and placement.
6. Displaying a modal form while another modal form is displayed
decreases available memory.
Explanation:
Showing a modal from from another modal form takes memory from the
far heap in direct proportion to the number of controls on the
secondary form. The problem is that when the the second form is
unloaded, the memory is never returned to the far heap. Eventually
the program will crash. This holds true for all modal forms, even
MSGBOX.
Solution:
If you have a small program, you can simply never unload your forms,
just hide them. For a larger program this is not viable. In the
secondary modal forms, when the event that triggers the closing
process occurs, hide the forms. In the primary form's Unload event,
unload every form that *may* have been loaded. Attempting to unload
a form that has not been loaded causes no runtime errors, it is just
ignored.
As in #5 above, if you want to be able to use MSGBOX's
functionality, you will have to write your own since MSGBOX unloads
its own form.
7. Asking for help on a Type structure in the help window locks up the
system.
Explanation:
When you place the cursor on a variable in the code window, and
press <F1>, the IDE shows you the variable's range, its type, and
each procedure and module that it occurs in. When the variable
is of a user type, placing the cursor on the type name and pressing
<F1> gives you the type structure. As far as I can tell, this is a
toss up error that occurs when a certain memory boundry is passed.
Solution:
If your filling up memory, don't press <F1> on the type name, or
save your work before you do. Sorry, no magic cures for this one.
8. Editing a form in the Forms Designer (FD) and returning to the IDE
does not save changes made to Text properties and the default option
button.
Explanation:
When you return to the IDE after making such a change, the text
property and the default option button remains the same as it was
before you changed them.
Solution:
Prior to editing the form, save the form as binary. You will need
to do this in the IDE as FD has no options to save as binary or
text. Make the changes in FD. Go back to the IDE, and save again
as text. You will want your code to be saved as text anyway because
if you remove references to a variable in your code, descriptions
for the variable are kept in the source file, resulting in longer
load time, and less available memory.
9. Event order is not the same when the user presses a hot-key for a
command button.
Explanation:
When the user selects a command button by clicking it with the
mouse, event execution is as such:
Current object's LostFocus
Command button's GotFocus
Command button's Click
If the user presses the <Alt> + <Hotletter> combination, the event
execution is:
Command button's Click
Current object's LostFocus
Command button's GotFocus
Solution:
Make the first line for each click event:
Dummy = DOEVENTS()
This will make the system process the LostFocus and GotFocus events.
>>> Continued to next message
* SLMR 2.1a * Help me! Someone turned reality back on.
--- Maximus 2.00
* Origin: The Line Source BBS, Maximus [CBCS] (717)236-1375) (1:270/116)
