I'm developing a Firemonkey Application wich should run on Windows with touchscreen.
Because I have no touchscreen for my development system, I can't test the behavior of some controls. For example the panning in a TListbox doesn't work with the mouse-button. It only works if ssTouch in KeyState is set.
Is there a way to simulate the touch via the mouse?
Regards,
Michael
Well, aside from the obvious answer (save up and get that touchscreen!), there are some solutions, but they might be a bit involved.
If I wanted to do this on PC, I would start by making a copy of the Firemonkey source code and including it in my project.
After checking to see that your 'local' copy of Firemonkey is compiling properly, you will have to edit this file: "FMX.Platform.Win.pas". Open this file and then search for "ssTouch".
Inside of the WM_LBUTTONDOWN handler, there must be some logic which determines whether "ssTouch" is part of the KeyState or not. Add it in yourself, and then the left button should be evaluated as a touch input.
Related
I have a really solid computer program that was written for Windows XP. The program still works great and I would like to update the look and feel of the user interface.
At this time, I would like to give the buttons etc. a more sleek, contemporary look. Much better would be to allow functionality of touch and swipe etc. for tablets and such.
Can anyone tell me what tools in Delphi are used to accomplish this? For instance, do I need to change every button and object manually through object inspector or can I update/modify all objects objects within a project using a single set of commands?
You can start by enabling Windows themes, using Project->Options->Appearance from the IDE's main menu. It's on by default since D2007, but won't be on because your app is coming from Delphi 5. (New projects have it turned on by default, but the IDE can't know if you want it enabled or not when importing older projects.)
You can then start looking at adding gesture support by looking into the documentation for TGestureManager and TGesture. There's a TGestureManager for both VCL and FireMonkey (FMX) applications.
Note that for cross-platform support (Android, iOS, and OS X) you'll need to port your application from the VCL to FMX.
I am coding up a VST plugin dll. I have no trouble with the plugin until I use a PageControl and place controls on it.
Specifically, my dll seems to have trouble receiving mouse clicks if the control I click on is in a tabsheet, and has code to execute in a mouse onclick or onChange event. However, this ONLY occurs when the hosting program gives control back to my plugin. I can interact perfectly fine with the plugin before the hosting program implements the settings I select, but once it tries to hand back control, I can only click on, seemingly, any control that does not implement any written mouse event code (Tlabel clicks are fine, tabsheet changes are fine too).
The plugin works fine as long as I don't try to make changes to the settings through the controls after the hosting program hands back control to the dll. I can use the same settings over and over again with no problem. I can change them as much as I want until I let the hosting program implement the plugin values (which works perfectly).
This is really tricky to debug since the program is in a dll.
I have tried using Delphi XE2 and Delphi 2009.
Any clues?
Using the 'standard' VCL drag and drop events OnDragOver and OnDragDrop, how can I distinguish between "Copy" and "Move" operations?
I don't seem to have a TDragType available, and the keyboard Shift state isn't passed to these events.
This is not something you can determine from the events because the events make no assumptions about your application needs or capabilities.
Interpreting a particular drag/drop as having any particular semantics is the responsibility of the application itself - the OS cannot know how the application will react to the dropping of a file so can make no assumptions about what the dragging operation may imply for the user.
For many applications there will be no distinction between copy/move, there will be just drag-and-drop.
The copy/move distinction is something that Windows Explorer applies to file operations. For "vanilla" drag/drops it applies rules based on original and destination drive volumes - dragging/dropping files around on a volume is a move operation, by default. Dragging/dropping across volumes is a copy, by default.
But these are only default rules determined by the application (Windows Explorer). The user can override these default using keyboard shortcuts during dragging and (most importantly) when dropping. But these are defined and interpreted by the particular application - i.e. Windows Explorer - not the OS.
So, if you're application is a drop target for files that may be dragged from Windows Explorer, and if it makes sense for your application to discriminate between copy and move, then you may need to support the same keyboard modifiers that Windows Explorer supports. I don't believe these are modifiable (although I'd advise this be confirmed), so you could simply test the state of the Ctrl or Shift keys in your drag events:
Ctrl = COPY
Shift = MOVE
Ctrl + Shift = MAKE SHORTCUT (if this is applicable to your application)
GetKeyState() can be used to directly interrogate the state of a specific key at any given moment in time.
If a varying "default" behaviour is desired then you would have to apply your own tests to the source information to determine which default makes most sense (i.e. to mimic the Windows Explorer "volume boundary" default rules), or simply choose the most appropriate or intuitive default action for your application.
The short answer is - you don't. The VCL's built-in drag-n-drop system does not distinquish between the two. You can, however, derive your own TDragObject/Ex classes to control what kind of data actually gets dragged around.
If you want to use Drag'n'Drop between your application and other Windows applications, it's worth looking at Anders Melander's Drag and Drop Component Suite for Delphi.
The latest code being here.
Not sure about Delphi specifically, but in C# you check the AllowedEffect property of your event parameter. Since they both link back to Win32 I can't imagine there is much difference.
http://msdn.microsoft.com/en-us/library/system.windows.forms.drageventargs.aspx has a good example. Hope this helps!
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)?