corneliusdavid

Just an additional tip... You can right+click on an object (or group of objects) and select Hide Element(s) to hide ones you're not interested in. You can also put groups of components into Layers to only show a limited set at a time to make working in the LiveBindings Designer easier to manage.

I guess the idea is that since a DFM is a design tool, you can see and access the components directly without needing to search. Delphi's "Find in Files" only searches the code files (.PAS) and project files (.DPR, .DPK, .DPKW) unless you change the "Where" selection to "Search in Directories." I seldom need to search .DFM files--and then I use an external search tool.

By default, the LiveBindings Designer will show all objects, allowing you to hook them up. When you hook them up, lines appear between the connected ones. If there are no connections, your app is not using LiveBindings. In this screenshot, only two components are connected: Hope that helps!

Delphi forms and data modules are comprised of two physical files: 1) .PAS, and 2) .DFM. The .DFM contains all the components and properties set up at design-time in the Delphi IDE; the .PAS file is the "code-behind" or the logic that makes it all work. The queries are stored in the SQL property of query objects, just another text property of a component on the form; thus, they're stored in the .DFM. What you're (likely) seeing in the version control is a difference in the .DFM, not the .PAS file. Your code (.PAS) may not have changed but if a query does, then your .DFM would change.

FWIW, both plugins installed and restarted the IDE without error for me.

That's not similar at all. Ctrl+Shift+C is Class Completion; use Alt+UpArrow or Alt+DownArrow to jump between implementation and interface of a method. Neither of those are what I was describing.

Done. :-)

Yes, it does. In one project I did a while back, I separated the functionality into three different data modules, each with a TActionList and the main form used all three data modules. When selecting an action on a control, all actions from all data modules were available, easily identified by <Unit>.<Action>.

I use actions a lot. In fact, sometimes I group related sets of actions into data modules, then use the data modules in the forms. Instead of double-clicking event handlers and calling procedures to do the work (or Execute methods of actions), just hook the actions directly up to the controls. The caption of the TAction becomes the caption of the menu or button; the Execute event of the TAction becomes the OnClick event handler of the Menu or Button. You can also provide icons for the associated controls right within a TActionList as well. Later, if you decide to change the user interface from using menus to using buttons (for example), you don't have to change the captions or event handlers but just assign the TAction! There are many other ways and probably some more "pure MVC or MVVM" but this has worked really well for me.

There's probably an OnChange or OnExit event handler for that DBEdit that is doing the automatic save. DBEdits have a DataSource property so you can reference the underlying data source with that property. DBEdits also have a DataField property which points to the field in the database for which the value is read and written. Delphi's VCL provides DBEdits as a convenience and watches when the focus leaves the control to update the data set held in memory until the entire dataset is posted back to the database. So you could simply add one line to your ButtonClick event to change the focus after the text is set: DBEdit86.SetFocus; assuming there's a DBEdit called DBEdit86. Perhaps just switch focus to the OK button or some other control. (There's also a way to just switch focus to the next control in the window but that escapes me at the moment). But a better way would be to do this programmatically (instead of trying to mimic what the DBEdit has to do), something like this: procedure TfDesignMaster.NoUPCButtonClick(Sender: TObject); begin DBEdit85.DataSource.Edit; DBEdit85.DataSource.FieldByName(DBEdit85.DataField).AsString := 'NO UPC ON ITEM'; DBEdit85.DataSource.Post; end; Now, assuming you know what the DataSource is, you can list it explicitly instead of referencing it with "DBEdit85.DataSource"; same with the FieldName--I just used the information I had here. For example: procedure TfDesignMaster.NoUPCButtonClick(Sender: TObject); begin InventoryTable.Edit; InventoryTable.UPC.AsString := 'NO UPC ON ITEM'; InventoryTable.Post; end; There are a couple of gotchas you need to understand that only you will be able to answer by looking at the code in that form: Is the DataSet already in Edit mode? If so, you don't need to call .Edit. Will other edit controls or application logic expect the DataSet to still be in Edit mode after that button is clicked? If so you don't want to call .Post (or call .Edit again immediately after). There are probably several other considerations but this is a start.

Uh, how do you expect to get the contents of a file without opening it? Or do you mean that you don't want to use OLE? I've used XLSReadWrite successfully.

So since you can't find one, just write your own. It shouldn't be terribly difficult. You could probably even calculate the RGB value based on the number given.

It's not Delphi that needs the path set--it's Windows. Windows doesn't use the registry to find and launch the application--dcc32.exe in this case. The first instance of dcc32.exe that Windows finds in the PATH is the one that runs. And by default, the last version of Delphi installed will be the version of dcc32 that automatically launches because installing Delphi prepends the system path with bin folder of that version of Delphi.

I think @Stompieis right. Even though you're running it from the Studio 17.0 (Delphi 10 Seattle) folder, it might be picking up the path for the newer version of Delphi instead. On my main development machine, I have only Delphi 10.4 and 11 installed. I ran dcc32 --version from both the "21.0" and "22.0" folders: And it picked the same one, the Delphi 11 version, both times. It used to be that Windows would look in the current folder first to run an application but I think it now looks through the PATH environment variable first. A reference sheet I keep handy shows the relationship between the compiler version, the product name, the Delphi version, and the Studio version: VER300 - Delphi 10 Seattle (Delphi 23, Studio 17.0) VER310 - Delphi 10.1 Berlin (Delphi 24, Studio 18.0) VER320 - Delphi 10.2 Tokyo (Delphi 25, Studio 19.0) VER330 - Delphi 10.3 Rio (Delphi 26, Studio 20.0) VER340 - Delphi 10.4 Sydney (Delphi 27, Studio 21.0) VER350 - Delphi 11 Alexandria (Delphi 28, Studio 22.0) When I ran the folder-specific version of dcc32, it used the correct one:

My favorite and most used feature of the Parnassus plugin is in the Navigator plugin with it's Go To Shortcut. With a default hotkey of Ctrl+G, it drops a stack-based bookmark, incrementally searches as you type a destination, jumps there once you select it, then Escape takes you right back. I'm often going up to the implementation section to add a unit to the uses clause and then want to continue where I was at. This is a huge productivity boost for me. Most of my development is still in 10.4.2 but I know there are other IDE plugins and shortcuts that could get me close if I move on to D11. Or I could try and remember the built-in keys that do the same thing: Drop a stack-based bookmark: Ctrl+K, Ctrl+G Go to the Navigation Toolbar for Sections: Ctrl+Alt+N, Ctrl+Alt+S Pick up the stack-based bookmark: Ctrl+Q, Ctrl+G YUCK! References: Using the Bookmark Stack: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Using_the_Bookmark_Stack Using the Navigation Toolbar: https://corneliusconcepts.tech/delphi-productivity-tips-navigation-toolbar

Well, there is that.

At this point, I'd contact Embarcadero support. It's an installation issue that renders use of the product inoperable so would be a free tech support incident.

I have only used it briefly here and there. What are the limitations you've run into?

How does it compare with Delphi's TZipFile?

OK, I finally see what you're getting at. I got sidetracked by just the idea of simple editing of text on a mobile device and missed part about the ControlType--sorry. (I had recently experienced frustration when typing a long text and trying to view/edit the whole thing--and that was using the phone's built-in text messaging app--I thought that's where this was going.) I ran a sample project and switched the ControlType property of the TEdit between Styled and Platform and now see what you've been trying to explain. Yes, the "Platform" control works properly but (and as explained on docwiki) does not respect the z-order. So, yeah, it does look like a bug, or incomplete feature implementation, in the styled version of the TEdit.

Have you tried other apps on Android that have a small text edit input to compare how they act? @Lars Fosdaldescribes how it can be done on Android--and yes, that works but I have problems getting it right so more often just backspace or don't even try to scroll. Same thing on iOS.

Interesting. You might try adding the IDE Fix Pack, then: "fastdcc applies the Compiler Speed Pack that is included in IDE Fix Pack to the command line compilers dcc32, dcc64 and dccaarm (XE6 and newer)"

Right. That's typical on a mobile device--it's not specific to Delphi apps. Basically, you can type forward or backspace to clear it out and type it over. That's why I sometimes hook a Bluetooth keyboard up to my mobile device when I'm writing lots of text--I can use the keyboard arrow keys to navigate past the beginning/end of the visible text. Have you ever sent a long text message with a phone? It's a pain if you've been typing fast then look at what you've typed and realized there's a misspelled word in the middle and you have to somehow select it and type over without losing it or finger-swipe to go back to the top of the paragraph to make sure you didn't miss anything. You could set the MaxLength property of the TEdit so the user can't type a bunch of text; or use a TMemo and make it fill up the screen so the user can see all the text they've typed. Welcome to mobile development!!

Are you referring to the lack of left/right/home/end buttons, or just the standard user interface on a mobile device? I've never had problems with TEdit text scrolling on mobile devices--I just hook up a Bluetooth keyboard if I want to be able to move the cursor through the text.

What version of Windows are you running on? Did you see any errors as you were installing Delphi? Can you try "step over" instead of trace into and tell is if it can step through code that way?