I noticed that the OnKeyUp event processing does happen for a TButton control when running my iOS application on my iPhone and my iPad (but I believe it does on the Windows emulator). The OnKeyDown event however seems to operate correctly. This looks like a bug to me, but I am not sure.
I have installed service pack 1 on my Delphi XE2 install and recompiled - same result.
You probably mean it does not happen. I experience the same thing, so I cannot say it's a bug or a 'feature' but I at least I can offer confirmation.
I changed my code to react on OnKeyDown instead of OnKeyUp, which is a pain because for edit fields for example the text property is only filled after your code is fired - basically you are always one character 'late'.
Related
Create a new project. Drop two TEdits on a form. Deploy to Android device. Start up App. Tap a TEdit to bring up the keyboard, hit the hardware back button on your phone... Crash... Is this something specific to me? or can other people confirm this? Is there something wrong that I am doing? I've tried setting the Key:=0 on the keydown event of the form and the TEdits but that didn't work - app still crashes.
Delphi XE7 update 1 installed.
Create a new project and add your classes to it. Problem is somewhere in the .dproj file
I'm currently porting old code from Borland C++ Builder 5 to C++ Builder XE (the newest version). There seem to be a lot of properties and some events that are not anymore supported in XE. Most of them have been set to default values anyway, so it was no problem to remove them. Now, however, I have encountered the following problem: The event OnKeyUp is not available for TPanels anymore! Why is that? How can I fix this? And how did an OnKeyUp event on a TPanel work anyway?
The OnKeyUp event still exists. It is protected in TControl, as it always has been. Descendants choose whether to promote it to public/published access. That has not changed. TPanel did not promote any of the OnKey... events in BCB5 (or any other version), so I don't know whay you could have been using before.
I'm using Tortoise SVN with Delphi 7 and I always have to check the dfm before I commit... but I have a Delphi 7 DFM which has somehow lost it's FormCreate and FormShow event handles! I know that moving the form inside the Delphi IDE causes the dfm to be modified (Top, Left.. etc), but I highly doubt that I removed the event handles manually... so I'm wondering if anyone has experienced anything like this before. Please share your experience. Thanks.
It sometimes happens, but do not know why. Mostly when using frames or inherited forms, and opening/changing a subframe/subform without opening the forms that use it. Or something like that... Cannot reproduce it, but weird indeed.
I have used Delphi for many years and it has never happened to me, but if the code is still there you could just double click on the event (FormCreate and FormShow) and they will be assigned again.
I have experienced this when initially sketching out the method and event structure. If I generate event handles, then move on and compile or run the program with an empty event holder, then CodeComplete will remove the empty handler. I have not encountered this problem in situations where the event handler is non-empty.
Make a Delphi 2007 application, TForm as main window.
Run application. Try to drag the form using the caption bar. The debugger shows an unending stream of error messages, complaining it can't find some unnamed routine. Escape and Break don't work. 3 finger salute doesn't work.
Clicking in some other window and then back to the Delphi application stops the avalanche of error messages and allows the application to function in its original location (the form itself hasn't moved).
Strangely, on occasion I've had related behavior using Firefox -- clicking in the browser window doesn't work 'til I click in some non-Firefox window, after which the browser window is active again.
Anyone seen related behavior? Suggestions? Might it be a mouse driver problem? Toshiba laptop with ALPS touchpad mouse.
This doesn't sound related to Delphi specifically. The "stream of error messages, complaining it can't find some unnamed routine" sounds very odd. Could you post one or two of the actual messages, please?
In the meanwhile, my guess is some form of hook or injected code. Try looking for programs that do that kind of thing and disable them one by one:
Mouse drivers (as a poster above
said)
Antivirus, especially the "big ones"
like Norton etc
Some display driver "enhancement"
utilities
If you have two screens and you're
running a second taskbar program, try
that
and so forth.
It's probably worth doing a virus scan too, you never know :)
I know there was a Logitech driver hook problem when starting a Delphi project in Delphi: it gave an exception on the first line of the .dpr. Outside Delphi it worked OK.
So do you get those exceptions/problems only in Delphi? What kind of error/exceptions?
How can I make my delphi systray app using standard vcl inputbox() function to request focus, now dialog box seem to remain in taskbar and dialog does not open to front of other apps. This is Vista issue I think. Creating own form would solve it I believe.
ps: I can edit dialogs.pas if needed, it seem to be using Tcustomforms.showmodal
You are probably using older version of delphi.
Some Vista specific workarounds for older delphi versions can be fond here.
Try Application.ProcessMessages; just before inputbox call.
Have you tried an application.BringtoFront() before you launch the inputbox?
Editing dialogs.pas seems to be a bad ide. I would rather make my own inputbox-form.
Applications stealing focus can be quite annoying, though... How do you launch the inputbox? On a timer, or on a userrequest (e.g. clicking on the icon)?