Leaderboard

IBExpert, as its name obviously means, deals with IB and FB. OP has Postgres. bug

In case somebody is interested this is how I managed to nicely integrate matplotlib figures inside my delphi app. 1) the pythons script shows the plot with "plt.show(block=False)" 2) this is the code which executes the script and embeds the plot procedure TForm1.Button1Click(Sender: TObject); var plotwnd:HWND; begin PythonEngine1.ExecStrings( Synedit1.Lines ); plotwnd:=Findwindow(nil,'Figure 1'); if plotwnd<>0 then begin Windows.SetParent(plotwnd,(PageControl1.Pages[1] as TTabSheet).Handle); SetWindowLong(plotwnd, GWL_STYLE, GetWindowLong(Handle, GWL_STYLE) and not WS_BORDER and not WS_SIZEBOX and not WS_DLGFRAME ); showwindow(plotwnd,sw_showmaximized); setforegroundwindow(plotwnd); end; end; the plot is displayed inside a tabsheet which has an event handler to automatically resize the plot procedure TForm1.PlotResize(Sender: TObject); begin movewindow(plotwnd,0,0,(PageControl1.Pages[1] as TTabSheet).Width,(PageControl1.Pages[1] as TTabSheet).Height,True); end;

Sad news I feel https://community.devexpress.com/blogs/ctodx/archive/2020/12/02/fmx-grid-future-plans.aspx For those of us hoping to port our VCL applications with minimal fuss one day. There are a few other FMX grids available, but at least on the VCL side, none of them are as good as Dev Express grids.

Yes, you could specify the broadcast IP of the desired network, and let Windows figure out which adapter to use. Alternatively, rather than creating only 1 Binding that is bound to '0.0.0.0', you can create multiple Bindings, one for each network adapter (looks like you are already enumerating the adapters anyway), and then you can call Broadcast() on each adapter directly. That will allow you to search multiple networks at a time.

The var has to be finalized before freeing the object: PySUBJECT := TPythonDelphiVar.Create(nil); try PySUBJECT.Engine := self.PythonEngine1; PySUBJECT.VarName := 'SUBJECT'; PySUBJECT.Initialize; finally PySUBJECT.Finalize; PySUBJECT.Free; end;

https://pastebin.com/YCiqiNAq Pretty simple but effective. Hasn't failed me yet.

Hi All Small progress update on DPM - https://github.com/DelphiPackageManager/DPM - some tweaks to make it possible to use DPM with projects that use runtime packages. v0.1.54-alpha Release https://github.com/DelphiPackageManager/DPM/releases/tag/v0.1.54-alpha Package compilation will now build version info if the package dproj has it enabled. There doesn't appear to be a way to pass that info into msbuild, so I plan to look at updating the dproj file with the correct version info before compilation. Implemented Copy Local feature for runtime packages. For projects that use runtime packages, dpm packages that produce runtime packages will be copied to the output folder. Copy Local is still a little rough around the edges... it doesn't detect if the project actually references the bpl's - that's more difficult than it sounds due to differences between dcp and bpl filenames (libsufffix comes in play here). So for now, you may end up with extra bpl files in your output folder if you use runtime packages. Fixed project group support on install command. Improved handling of relative project file paths. Cleaned up logging. Added batch file for downloading dev dependencies (only needed for developing DPM).

I'm once again in need of a good 64-bit profiler so I've been looking into what would be needed in order to generate PDB files from whatever Delphi can produce. First of all it seems the only good debug info source on the Delphi side is the MAP file and the format of that seems a bit unstable. However since it's a text file it should be easy to adapt to any changes in it. Then there's the PDB file format. The only good and reliable documentation of that appears to be what the LLVM project has produced. Microsoft at one time published some of their source code for dealing with PDB files but since then the repository appears to have gone into limbo and they have not kept it up to date like they said they would. Anyway, in short, a PDB file is a MSF container file consisting of a number of streams containing the different debug info in CodeView format. The MSF format is pretty simple and since I only need to produce PDBs I don't need to bother about decoding MSF files. That leaves the PDB CodeView streams. Thanks to the LLVM documentation their format are known. However, after reading the LLVM source, it has become clear that it would be a huge task to implement all the different stream formats and all the different data types. I guess one could get by with a subset but it doesn't really seems worth the effort to create something that only works sometimes. The biggest problem however is that I would be implementing something based on a port of a third party's interpretation of Microsoft's old (and by now out of date) source. PDB is an internal VS format and Microsoft has stated that it can, and mostly will, change with each new version of VS. For this reason they provide the Debug Interface Access API for those that need to read PDB files. Unfortunately there's no (known) corresponding API to write PDB files. PDB support is important for the LLVM project (they too would like VTune to work with their output ) so they appear to be trying to keep up with the PDB changes and since they obviously have more resources for that task than I do I've decided to aim for a solution that piggybacks on their work instead of rolling my own. The solution I'm going to try is to parse the MAP file in Delphi, write out the relevant information in YAML format and then use the LLVM llvm-pdbtil tool to convert the YAML to PDB. Sounds easy and it probably would be except for the fact that the required YAML format is undocumented... The llvm-pdbutil yaml2pdb documentation does a handwave with "The YAML syntax is not described here. Instead, use llvm-pdbutil pdb2yaml and examine the output for an example starting point.". Lazy bastards Anyway, this was just a dump of the information I've been able to gather on the topic of generating PDB from Delphi in case I burn out before completing anything usable.

Odd, this doesn't happen on my 10.4.2 test installation (and also not on my 10.4.1 installation). What does happen, is that the editor window loses focus. No idea where it goes. But that's not limited to GExpert's Open File and Delphi 10.4., it also happens without GExperts and e.g. on Delphi 10.2.

I have reproduced this error. GExperts is installed based on revision 3449. I can't say whether this error was before or not, as I rarely used 'Open file expert' from GExperts

Should be an (*1)array of (*2)pointer to libvlc_media_track_t passed by (*3)reference, no?