I have created a COM Interop Control in C# to use in my PB application. If I add an ole control to my userobject and select my C# object in the painter, then an olecustomcontrol is created and everything works as expected. However, in order to use a 64-bit version of my object when building the project for a 64-bit platform (in PB Classic 12.6) I added an ole control but hit cancel when asked to select an object, so an olecontrol is created and I can use InsertClass to select my object at runtime. This is working for me but I have one issue: when the user clicks in my control, activating it, the toolbar icons on my MDI window disappear. From the research I have done, it sounds like PB may expect the ole object to provide the menus and toolbars, but my PB menu items are unaffected, it is just the toolbar. My control does contain a toolbar (the control is a rich text editor I created to workaround some shortcomings of the built in control) but I have also tried creating a new Interop Control with only a plain text box on it and got the same results. Actually I also tried using one of the Microsoft controls (Microsoft InkEdit Control) installed on my system, and again got the same results.
Does anyone know how I can fix this toolbar problem? (I'm at a loss, but I'm guessing it may be that I need to somehow tell PB to ignore OLE toolbars and/or tell my C# object not to advertise a toolbar.)
Ah, that legacy code we have to support for decades...
The following would take some research and may not eventually solve the problem, but I'd give it a try. I'd implement a "proxy" COM object that'd serve as an extra layer between your .NET OLE control and its OLE container. Such object would be exposed as OLE control to the PB runtime, and as OLE Container to the .NET control, and forward the COM methods calls between the two. It'd be much easier to code this layer with C++/ATL, but it should be doable with bare C#, too.
Then I'd watch the calls made on IOleInPlaceFrame and IOleInPlaceUIWindow interfaces and block those which lead to the undesired toolbar behavior (if any). I'd also limit the set of OLE control interfaces exposed to the PB runtime to some bare minimum.
The implementation details of AxHost and Control classes might be helpful here, as well as the ATL library source code.
This seems a bug. I created a very simple application that retrieves data into ole control and there was no code in any menu items. As soon data is fetched and ole control gets focus the main MDI toolbar disappear. Somebody should report that bug to SAP.
https://answers.sap.com/questions/300798/toolbar-disappear-when-ole-control-get-focus.html
Related
Like the title says. I want to add an Object Inspector to my form at rum time, and when I click other components, it should have two way data binding with them.
That is, if I, for instance, change the top property of a TPanel in the object inspector, then the panel should move; and, if I drag the panel, the object inspector should reflect its Top & Left properties.
Of course, I mean this to work for all proprieties, and select a new component each time the user clicks one at run time.
I don't even know where to start :-(
[Update] I do know, however, that I would strongly prefer to use Delphi components, and nothing 3rd party
No, you cannot use the Object Inspector in your own code. It's a proprietary part of the IDE, and it is not available as source or a component. It never has been, and I highly doubt it will ever be. It's also integrated with the rest of the IDE (the Code Editor and Form Designer), neither of which are available as components either. It's functionality is contained in packages that are design-time only, and are not licensed for use outside the IDE (you can't use them in your application).
In addition, most of the property editors that are invoked by the Object Inspector are also implemented in design-time only packages that wouldn't be available to your application either.
I'm injecting a number of forms into an existing application using a dll.
I don't control the existing application, nor do I have source code for it.
(I doubt the source code exists any more).
I want to show a TextHint in a TEdit.
In the form designer this works, but in the application it doesn't.
I traced it to the fact that StyleServices (This used to be called ThemeServices (now deprecated)) is not enabled, disabling the TextHint.
Obviously I cannot enable styles for the application, all I have is a dll.
Is there a way to show the texthint?
I prefer to use a stock TEdit.
The dll is written in DX and the old application is written in D7.
BTW I don't care a hood about any additional styling/theming or the like. I just want the texthint to display.
Is there a way to show the texthint?
Standard TextHint functionality in a stock TEdit is dependent on the EM_SETCUEBANNER message, which only works when Visual Styles are enabled:
Note To use this API, you must provide a manifest specifying Comclt32.dll version 6.0. For more information on manifests, see Enabling Visual Styles.
If Visual Styles are not enabled in the app you are injecting your code into, then the only way to do what you are asking for is to subclass the TEdit window and custom-draw it manually when its text is empty.
I have deveoped a custom file type, together with a custom editor (basically a tree with several data pages attached and a few extra buttons). OK, I can run it stand alone and that is fine, and even add it to the tools menu, but I would like to integrate it into the Delphi IDE so that my custom editor (or a similar new version) appears in the IDE, rather like a DFM file has a custom editor. I can find references to most extensions in the Delphi IDE, but not this one. Any guiding hands? Note that this is not a property or component editor (the file type has nothing to do with either of these) nor is it simply syntax highlighting of a text file.
AFAIK it currently isn't possible to reliably integrate a custom editor into the Delphi IDE. The required API simply isn't there. See QC89028 Custom Module support.
During the Delphi 2010 and XE betas I spent most my spare time trying to get a resource editor integrated. Although the effort had the official blessing of Embarcadero and got some, half hearted, support from the IDE engineer, I was never able to get them to deliver on their promises and surface the module API. I eventually abandoned the project.
Update: I've now checked my old correspondence regarding this and it turns out part of the problem was that IOTAModuleCreator (used to implement File|New for custom file types) and IOTAEditorContent (used to transfer data to/from the custom module) only supports text data. Binary data gets mangled.
You can probably do this via an IDE plugin that uses the ToolsAPI (see ToolsAPI.pas in the IDE's source folder (e.g. Program Files (x86)\Embarcadero\Studio\source\ToolsAPI\ToolsAPI.pas.)
For information on writing a plugin in general, see David G Hoyle's excellent blog. Once you know the basics - i.e., write a 'wizard' and get it to do something - you will need to work on integrating your editor.
I have never done this, and so I can't guarantee it is possible. However, some interfaces that look worth investigating and implementing are INTACustomEditorView, which represents a 'view' (file tab when that file is open - think the code editor, Welcome view, type library editor, etc) and IOTAEditorViewServices, to register your custom view. I do not know how you associate a view type with a file type, sorry - possibly something to do with the personality interfaces. You might also be interested in INTACustomEditorSubView which is what creates a tab on the bottom of a file.
Good luck, and if you find a solution please write here so that other people can learn too!
The problem: I need to obtain the selected text from a window in a Windows application (not my program). I am doing my work in Delphi XE and the software I am attempting to access is a kluge built over the past 15 years with C, C++, VB and who knows what else. I do not have the source code. The edit box (an RTF memo) I am attempting to read is of the class "Ter32Class". When I use wm_copy, nothing goes to the clipboard. when I use wm_gettext, nothing. When I use wm_keydown commands (to simulate Ctrl-Ins or Ctrl-C) nothing happens. Note that I can get all of these alternatives to work in wordpad, notepad, and FireFox but not this application (or OpenOffice, incidentally, but that's not the issue). The only way I have been able to programmatically obtain text from this box is to use autohotkey with the simple "send ^c" command. While it works, it is inelegant. HELP?!?
More information: Window hierarchy: Ter32Class is a child of OI_Mdi which is a child of MDIClient, which is a child of OI_Window . I am drilling down to obtain the appropriate handle as it will respond to a paste command.
I am using Delphi XE but I'd love any solution in C++ or VB if no Delphi XE gurus have the answer.
From Quick Macros Forum
One of the windows I need to talk to is of class Ter32Class which
apparently is a TE Edit Control, an editor that doesn't inherit from
the standard RichText Control
and
The published method of talking to this control is via it's DLL
so unless something has changed (post is 2006), it appears you'll need to use it's dll to get the text.
From Sub Systems (TE Edit control website)
Application Interface functions
GetTerBuffer: Retrieve Window Text
HANDLE GetTerBuffer(hWnd, size)
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!