ULIK

Peter, what's your point? If you don't like that feature, deactivate it. I use it often for navigation between extracted code and original position, so I find it very useful.

MMX 15.1.7, Delphi XE 11.3 When opening the drop down menu for visibility icon, icons seems to be missing (as far as I remember earlier versions had shown it) :

Just some general thoughts about such an upgrade: - what exactly is the reason for upgrade? Is there a real business case to port? Or is it just because someone wants to use the new fancy things from newer Delphi versions? - as you are asking for a large-scale EHR system: do you and your team have the resources to do it over probably several months or even years? - if the current system is actively developed: can you handle two source branches that may differ heavily over months/years? - as a port to Unicode is involved: what about your existing database? Can it handle Unicode already or is it necessary to upgrade database too. Are existing data ready for Unicode or does it need to be updated too? - check, how good or bad the separation between UI / logic / database already is. Can it be improved on the current D6 system? If so: do it there, where applicable, so that you can see any problems soon and under real conditions. - 3rd party: try to consolidate if there are too much different component collections involved. - new UI features: forget about them at least for the moment. First try to port your application(s) to D12 and then introduce new UI. Only if a new UI components will help you to reduce/replace a lot of existing code or are unavoidable for port, consider adding it. But make sure, that new UI is consistent regarding user input with remaining older UI system. Your end users will be grateful. Depending on who the end users are: are they willing to accept larger changes on UI? Have in mind that training for them may be necessary and who has to pay for it.

Curious, this problem is not restricted on Delphi 12 Athens, You can also see it on (at least) Delphi 11.3 Alexandria. It not necessary to install all that 3rd party libraries. Just DevExpress or ImageEN should be enough to see a relevant delay when opening standard actions. This makes me wonder why none of that vendors have already reported this to Embarcadero.

Uwe, where do I find this groups dialog? Is this a new feature you are working on? Found it! Thanks!

Thanks!

I played around with this expert and added two things: - display with gutter: - two buttons to refresh or clear results: refresh can be used, when typing something on editor itself that modifies the result positions. If you like it, feel free to add it to repository. Please note: all modifications were only tested on Delphi XE11, but they should run on earlier versions too. As I'm not familiar with GX development: I have simply assigned two icons from GX Icon folder to speedbutton glyph, which probably is not the common way for GX. So you might change this to better fit the GX universe. Attached is a patch file with my changes: InstantGrepWithGutter.patch

Minor glitch: label l_PressEsc should set Layout to tlCenter to align it with checkbox (but I'm not sure, if this property is available back to Delphi 7). A suggestion for an interim solution for the missing 'Original Position': procedure PaintFileHeader(_Rect: TRect); ... LineText := Format(SLine, [Res.Idx + 1]); // Add additional text for original position, which is always the very first entry on listbox if _Index = 0 then LineText := LineText + ' (' + Module + ')'; ... You might also use a different color for original position: procedure PaintLines(_Rect: TRect); ... if odSelected in _State then begin BGNormal := clHighLight; LbCanvas.Font.Color := clHighLightText; BGMatch := BGNormal; end else if _Index = 0 then begin // as original position is not a real result, just let it gray BGNormal := clBtnFace; LbCanvas.Font.Color := clWindowText; BGMatch := BGNormal; end else begin BGNormal := clWindow; LbCanvas.Font.Color := clWindowText; BGMatch := RGB(250, 255, 230); end; Just some ideas, but a gutter would be much better. Feel free to add what you like.

I have attached you a Subversion patch file. It's just a quick&dirty change, so have a look on it (especially for the new resource string. This might not be necessary). GX_GrepInstantGrep.pas.patch

I have change the code a little bit and this is my current result of Instant Grep dialog: If the active editor file changes, the dialog changes it's caption too. If you are interested, I can send the necessary modifications.

Next thing I noticed: I placed the window on a second monitor right beside the maximized IDE main window on first monitor. No problem. Now I closed Instant Grep and opened it again: the Window is placed on my first monitor instead of second one. And how do I clear a former hit list? Entering a blank search phrase does not clear it. Also closing and reopening does not clear it.

Doing a first short test: I was irritated as every hit is divided be the filename. As Instant Grep displays it's result only based on current editor file, why not just add the filename only to caption (see attached image)? Second: I compiled the current source, closed Delphi 11.3 and installed the new DLL. Now the first start showed that error: Following starts do not show it anymore. And why is the roaming profile? Shouldn't this be stored on LOCAL_APP_DATA? Third, if there is no hit I would not show the entry 'Original Position'. At first I wondered, if this was a wrong hit of grep search, because I see something on result list I do not expect. If you want to show the original position, make it more clearer that this is *not* a search result. kind regards, Ulrich

If I remember right: yes, it should work.

Hi, when I print an image using GDI+ DrawImage method on a high DPI system (192 DPI), the result differs from what printer is used. Next is my test code: procedure TForm1.Button1Click(Sender: TObject); var DC: HDC; gpGraphics: TGPGraphics; gpImage: TGPBitmap; gpPen: TGPPen; nLogPixUI: Integer; nLogPx: Integer; png: TpngImage; rDest: TGPRectF; rectImage: TRect; rectImage72: TRect; begin memo1.Clear; // Just to get some information on the image png := TPngImage.Create; try png.LoadFromFile('image.png'); memo1.Lines.Add(Format('PNG.Width: %d', [png.Width])); memo1.Lines.Add(Format('PNG.Height: %d', [png.Height])); memo1.Lines.Add(Format('PNG.Res: %d, %d', [png.PixelInformation.PPUnitX, png.PixelInformation.PPUnitY])); finally png.Free; end; if PrintDialog1.Execute(Handle) then begin Printer.BeginDoc; try gpGraphics := TGPGraphics.Create(Printer.Canvas.Handle); try // let's use pixel gpGraphics.SetPageUnit(UnitPixel); // get device DPI DC := gpGraphics.GetHDC; try nLogPx := GetDeviceCaps(DC, LOGPIXELSX); memo1.Lines.Add(Format('Log. Pixel Device: %d', [nLogPx])) finally gpGraphics.ReleaseHDC(DC); end; // and create an image rectangle based on some MS Ink coordinates nLogPixUI := Screen.MonitorFromWindow(Self.Handle).PixelsPerInch; memo1.Lines.Add(Format('Log. Pixel Screen: %d', [nLogPixUI])); // create the image rectangle, based on a 90x90 pixel rectangle (just for test) rectImage.Create( MulDiv(10, nLogPx, nLogPixUI), MulDiv(10, nLogPx, nLogPixUI), MulDiv(100, nLogPx, nLogPixUI), MulDiv(100, nLogPx, nLogPixUI) ); // center coordinates system on image midpoint gpGraphics.TranslateTransform(rectImage.CenterPoint.X, rectImage.CenterPoint.y); gpPen := TGPPen.Create(ColorRefToARGB(ColorToRGB(clRed)), 1); try // create a red rectangle around the image gpGraphics.DrawRectangle(gpPen, - rectIMage.Width/2, - rectImage.Height/2, rectImage.Width, rectImage.Height); // load the image gpImage := TGPBitmap.Create('image.png', False); try memo1.Lines.Add(Format('Img.Width: %d', [gpImage.GetWidth])); memo1.Lines.Add(Format('Img.Height: %d', [gpImage.GetHeight])); memo1.Lines.Add(Format('Img.Res: %f, %f', [gpImage.GetHorizontalResolution, gpImage.GetVerticalResolution])); // create the destination rectangle for printing based on rectImage rDest.X := -rectIMage.Width/2; rDest.Y := -rectIMage.Height/2; rDEst.Width := rectIMage.Width; rDest.Height := rectImage.Height; gpGraphics.SetInterpolationMode(InterpolationModeHighQualityBicubic); gpGraphics.SetSmoothingMode(SmoothingModeHighQuality); gpGraphics.DrawImage(gpImage, rDest, 0, 0, gpImage.GetWidth, gpImage.GetHeight, UnitPixel); finally gpImage.Free; end; finally gpPen.Free; end; finally gpGraphics.Free; end; finally Printer.EndDoc; end; end; end; When I run this code against the attached image (see below) on a 96 DPI desktop system, everything is fine when printing on Microsoft PrintToPDF as well as any other installed printer: Next I run the same code on a SurfacePro 7 with 192 DPI. Now the result differs from used printer: HP Universal PS as well as SnagIt produce the expected output: But Microsoft Print to PDF, OneNote for Windows 10 and a HP Laserjet 400 MFP M425dw (607BA1) printer creates a wrong output: rectangle size is fine but content not. So the question is: why produces the output on different printers different outputs? It looks like the wrong output includes some scaling between 96 and 192 DPI but DrawImage should be independent of it, when setting source, destination explicitly. Especially why this is printer dependent? Any ideas, what causes this problem? Thanks, Ulrich forgot to mention: Delphi XE 10.2 Tokyo used image for printing:

I finally found a solution for this problem: the PNG images I printed had no pHYs chunks set (as they were initially created during runtime). As soon as the missing chucks were added, printing from high DPI systems works fine. The point is: it doesn't matter what exact values you are using, it's just that those chunks had to be set to a somewhat reasonable value. function TPaImageStrokeHelper.FixPNGPixelInformation(APNGImage: TPngImage): Boolean; begin Result := False; if not Assigned(APNGImage) then exit; if not APNGImage.HasPixelInformation then begin APNGImage.PixelInformation.PPUnitX := 3780; // relates to 96 DPI: 3780 Points / Meter APNGImage.PixelInformation.PPUnitY := 3780; APNGImage.PixelInformation.UnitType := utMeter; Result := True; end; end;

Oh, didn't realized that you also added an exe. You're right: running your exe I can reproduce this behavior when styles are active.

I just tested your project against 10.2 as well as 11.3 and both do not show that behavior. Here the messages stop as soon as mouse stops, styles active or not.

D11.2, latest MMX Build 2540: I have a problem when closing a running app inside IDE: Editor layout switches back from debug desktop to standard desktop. and then an access violation occurs inside MMX code explorer (which is hidden on debug, but docked in standard desktop). The AV does not happened every time but frequently enough for a report 😉 . And I have seen this on several different projects over the last months. Do you have an idea what could cause this? Attached is part of written full bug report. Thank you! bugreport_IDE_MMX.txt

After 5 hours of work there was no AV when switching between layout with and without MMX Explorer docked. So far it looks like you have fixed the problem. Thank you very much for looking on this problem!

Hi, if you need to get a working solution, you have to use a third party solution for creating a PDF. Why not use SynPDF as suggested? Easy to use, they offer sample code (read their start page til the end!) and there is even a forum where you can ask.

Thanks for the hint. Will try it today. As I get it frequently (but not every time): let me know if I can do some debugging for you. kind regards, Ulrich

MMX 15.1.4 2540 Delphi XE 11.2 (Delphi 11 Version 28.0.46481.1287) started DPI unaware on 96 DPI primary monitor when I rename a method on class explorer, the resulting dialog is a little bit too small on lower text part:

Yes, happens here too.

Then you can't use ObjectAtPoint . You will have to write your own version of it (not that hard, just iterate over all the children and see if position is inside and if it is visible. If so, do the testing on that found control again to get the inner controls of it (if any).

What do you mean by nope!? Definitely HitTest = False is the reason, why ObjectAtPoint will not recognize the button. You had to step through all the inherited calls down to TControl. ObjectAtPoint. Here the line if PointInObject(LP.X, LP.Y) and CheckHitTest(HitTest) then is the critical part. The first condition is true if over a button, but the second one makes it always fail. Btw: you had to call ObjectAtPoint with Screen coordinates: LIControl := ObjectAtPoint(ClientToScreen(LPointF));