To prevent repeating, you could always wait until the key is released:
[code] If Keyboard.AsyncAltKey Then
If Keyboard.AsyncKeyDown(&h23) Then
// Wait for key to be released
While Keyboard.AsyncAltKey And Keyboard.AsyncKeyDown(&h23)
Wend
MsgBox("Alt-P pressed")
End If
End If[/code]
Well, after a couple or more failed attempts to get this post in here (coz the forum kept losing it’s connection to the server), here goes…
Unfortunately nothing is preventing that error from raising it’s ugly head.
I got the Async stuff working fine and re-programmed my app to use that method (via a timer) on all of the windows. I even used this for the Alt+X to exit the windows … still crashed. Then I disbled the Alt+X and utilized the Escape key in the Windows KeyDown event to close the windows … after several opening and closing of the windows, the program crashed again, and again with the same RBGUIFramework.dll error.
This app MUST be operated using the keyboard, not the mouse.
Have you tried narrowing it down to a sample project that crashes and could be attached to a bug report?
I have started messing with a sample project but so far haven’t been able to cause it to crash… gonna continue “messing” with that but the concern is… how far does one go?
Big thanks to all so far for your help on this …
Would be helpful to know exactly what the purpose of the file RBGUIFramework.dll is. When is it called? Who created it? Could one not provide the developer of it with the crash info?
[quote=39466:@Rick Yerex]
Would be helpful to know exactly what the purpose of the file RBGUIFramework.dll is. When is it called? Who created it? Could one not provide the developer of it with the crash info?[/quote]
That IS the runtime framework for GUI applications created by Real Studio / Xojo
Sending a bug report with a sample project to us would go a long way to figuring out whats wrong
[quote=39470:@Norman Palardy]That IS the runtime framework for GUI applications created by Real Studio / Xojo
Sending a bug report with a sample project to us would go a long way to figuring out whats wrong[/quote]
I’ll try and duplicate it with a sample project.
You can create a feedback bug report & attach your project privately
That way only you & we can see it
OK, this is getting even worse … it crashed while I was making some changes in the IDE. Re-opened it, went to do a “Find All” … entered what I wanted to Find, then started entering what I wanted to Replace … and it crashed … SAME ERROR! WTF?
Going back & forth in here everyone’s kind of guessing at whats wrong.
A feedback report would make it possible for us to help you out better.
Hi Rick, did you try deleting the caches for XOJO??
ummm… how?
this is not a web app.
[quote=39610:@Norman Palardy]Going back & forth in here everyone’s kind of guessing at whats wrong.
A feedback report would make it possible for us to help you out better.[/quote]
Done
UPDATE:
I swapped the use of the Alt key to Ctrl key.
Also sub-classed my ComboBoxes that I use on several windows so that they get populated on Open … this way I am not programmatically populating them (within the Window’s Open event) each time a Window is opened.
So far, no crash.
UPDATE
I am not getting where I need to go with this Alt-key or Control-key method of doing things.
WINDOWS standard is to be able to use the Alt key in combination with various menu choices and Buttons when a specific letter of that menu choice is underlined. The way this is done is to precede the letter with ‘&’ (ampersand). This is common in developing Windows based apps.
Since the application continues to crash using this method (that RBGUIframework.dll thing), I’ve resorted to a whole lotta extra programming to accommodate the use of the Control key instead utilizing a timer as suggested.
UNFORTUNATELY … no matter what I do (so far), what I’m finding is if a user holds the key too long (and that doesn’t take much), it will process that key combination multiple times.
For instance, I have 3 windows involved as follows (in that order)…
MainSearch
Address
Statting
Each window is programmed to be closed using Control+X
From the MainSearch, the Address window is opened.
From the Address window the Statting window is opened.
Closing the Statting window using Control+X should leave the focus on the Address window . Sometimes it does … but other times, if the Control+X is held just a tad too long, the Address window also closes (because the Timer code that processes the Control+X key on that window then fires).
How in the world can I get this thing to work the way I need it to using either Alt or Control (Alt being the preferred method as it is a Windows standard) ???
BTW, I have submitted a FeedBack report on the RBGUIframework.dll … so far no cure has been forthcoming.
I have a hard time understanding why, that such a robust programming environment such as this, can have such a BUG and nothing is being done about it, especially when I apparently am not the only person who has encounted the issue. (sorry for my venting but I am getting extremely frustrated and am wasting a lot of time trying to make this work when it really should be a non-issue)
Were you able to duplicate it with a sample project? If you can’t, then it points to some characteristic of your specific project. I have had crash situations in the past due to not cleaning up after myself. Explicitly nil-ing a few key variables resolved the issue. I don’t know if that is happening here or not, but there could be more going on.
Are the windows implicitly instantiated? Or with New?
[quote=41916:@Tim Hare]Were you able to duplicate it with a sample project? If you can’t, then it points to some characteristic of your specific project. I have had crash situations in the past due to not cleaning up after myself. Explicitly nil-ing a few key variables resolved the issue. I don’t know if that is happening here or not, but there could be more going on.
Are the windows implicitly instantiated? Or with New?[/quote]
I haven’t been able to duplicate with a sample project.
How do you “nil-ling” variables?
The windows are created/displayed by simply using .Show and when I am done with them, I use .Close
How should I do it differently?
Also, the crash seems to happen whenever I or a user processes the “Exit” button using Alt+X. This button is a BevelButton. I wonder if I should use a PushButton instead? Think I will try that today.
WeeeL … I changed all the “Exit” buttons to PushButton (they were BevelButtons) and so far, so good but we’ll see what happens when I turn it over to some users coz if anyone can crash it, they can LOL!
NOPE! did some more testing … I still get it to crash.
I have encountered a crash with this dll also. For me, it was performing a drag and drop between two listboxes. I have a feeling that this is not something inherent in a specific control, but the nature of how they are used. I’m still trying to get a handle on this myself. I’m finding that the same action will sometimes crash and sometimes not, so that’s why I don’t think it is in a control. On the plus side, I’m finally learning how to use the remote debugger. 
thanks for posting this Steve.
I have tried so many different “things” including alternate “work-arounds” to no avail. As I’ve posted (somewhere), this problem may cause me to discontinue developing in RB (XoJo) and go back to using MS Access & VBA. That saddens me as I had high hopes for this app to be created in some other platform than MS Access, not to mention the considerable number of hours I have invested in it so far (it is almost ready to go live).