I regularly use the EDB Manager Help, particularly for more complex SQL, reminding me how to write things.

I would like to be able to open the ELH file within my own applications, as there are contexts where users write SQL, and access to the manual would be useful. The ELH file is not a text file or XML ... & there's no list on Wikipedia for it as a file-type, so I guess maybe it has been created with some more standard Help Tool then perhaps compressed.

Has anyone else done this or have any idea how to?

Adam


I think Tim rolled his own on this. You could give them a copy of the pdf help (I use that when I'm not in EDBManager) or you could cheat

It will take  a bit of digging but open edbmgr.dpr and search for VK_F1. The first hit is

procedure TMainForm.ListViewSQLMemoKeyUp(Sender: TObject; var Key: Word;
 Shift: TShiftState);
begin
  case Key of
     VK_F1:
        begin
        FindHelpForKeyword(ListViewSQLMemo.GetKeyword);
        Key:=0;
        end;
     end;
end;

Follow it through.

Roy Lambert

Adam,

<< I regularly use the EDB Manager Help, particularly for more complex SQL, reminding me how to write things.

I would like to be able to open the ELH file within my own applications, as there are contexts where users write SQL, and access to the manual would be useful. The ELH file is not a text file or XML ... & there's no list on Wikipedia for it as a file-type, so I guess maybe it has been created with some more standard Help Tool then perhaps compressed. >>

I'm going to be moving this into a more standardized viewer with a component shortly. 2017 is all about modernization at Elevate Software, so there will be a lot of combining of components/code between DBISAM/EDB/EWB, including, but not limited to:

- The help manager/compiler (WinHelp has to go for the utilities)
- The UIs for utilities (updated to work with high-DPI and Windows 10)
- Web access to servers instead of built-in UIs
- The code editor used for SQL/Object Pascal code

So, please be patient.  The end result will be worth it, for sure, but it's going to take a few months to get it all straight.  There is a lot of duplicated code between the various products, and combining it will mean that an update to one product will produce a benefit to the other.  EDB was the big issue with this originally, because it had all of that Unicode/ANSI-specific string handling in it.  But, now that all of the products use the standard string type and mediate any conversions at the DB-handling level, they can now share components/controls.



Tim Young
Elevate Software
www.elevatesoft.com

Tim


>- The UIs for utilities (updated to work with high-DPI and Windows 10)

It'll be interesting having a poke around your code to see how you go about it. There's been quite a bit of discussion on the emb ngs a lot of which is way beyond me (or my needs). NOt having a 4K screen helps me to ignore it!

Roy

Roy Lambert wrote:

>  NOt having a 4K screen helps me to ignore it!

Whatever you do, don't get a 4k screen to go with an "ordinary" screen. Chaos and horrible. Just maybe Windows 10 latest has improved it, but it was a disaster for me.

Now, since I moved to the 5k iMac with extra 4k screen, all is lovely, but I use VMWare Fusion with its "pretend to be big pixels" mode, so Windows is its happy self.

I too would be interested to know what is needed to make my apps look nice though!

--

Matthew Jones

Matthew


>I too would be interested to know what is needed to make my apps look nice though!

Being somewhat of a luddite, old and bespectacled part of what I think is we need to stop believing we can actually see the difference

Reminds me of the old days when the hardware manufacturers were all screaming 16 million colours - oh so that's blue and that's a different blue is it? Never got that one either - the fact that I'm slightly (red, green, brown) colour blind helped!!!!!

Roy

Roy Lambert wrote:

> we need to stop believing we can actually see the difference

Oh we can! Well, I will admit it wasn't until I got new glasses that the retina screen vs "pixel" screen really became obvious. It is a bit like looking at an EGA screen nowadays, and you can't believe that was what we used to look at.

In Windows, things are more interesting, due to the lack of a decent mechanism to scale nicely. When I had my system, I could either get the 4k monitor to look okay, or the 1200 high monitor, but never both at the same time. Having a window across the two was quite poor.

They do seem to be working hard on it though, so it is coming soon. (But of course scaling has been a big issue for Delphi for a long time.)

--

Matthew Jones

Roy,

<< It'll be interesting having a poke around your code to see how you go about it. There's been quite a bit of discussion on the emb ngs a lot of which is way beyond me (or my needs). NOt having a 4K screen helps me to ignore it! >>

Yes, it will be interesting.  I'll try to communicate what I find out when I'm done.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


For you and other brave explorers who haven't already found it

http://news.helpandmanual.com/2014/11/a-delphi-developers-guide-for-4k-displays/

Roy Lambert

One more


http://zarko-gajic.iz.hr/writing-and-enabling-delphi-application-to-support-high-dpi-displays-and-4k-screen-resolutions/

Regards,

Hüseyin


Den 09-03-2017 kl. 09:08 skrev Roy Lambert:
> Tim
>
>
> For you and other brave explorers who haven't already found it
>
> http://news.helpandmanual.com/2014/11/a-delphi-developers-guide-for-4k-displays/
>
> Roy Lambert
>