dummzeuch

23 minutes ago, Angus Robertson said:

This all came from the Mustangpeak SVN at svn://www.soft-gems.net/mustangpeak eight years ago, but that is all gone now. 
 

Dual license:

// The contents of this file are subject to the Mozilla Public License
// Version 1.1 (the "License"); you maynot use this file except in compliance
// with the License. You may obtain a copy of the License at http://www.mozilla.org/MPL/
//
// Alternatively, you may redistribute this library, use and/or modify it under the terms of the
// GNU Lesser General Public License as published by the Free Software Foundation;
// either version 2.1 of the License, or (at your option) any later version.
// You may obtain a copy of the LGPL at http://www.gnu.org/copyleft/.
 

I don't really understand git, would be easier to upload all the Mustangpeak projects to my own public SVN server. 

 

Angus

If you insist on Github, you can simply create the project there and upload the sources using subversion.

Alternatively you could create a project on Sourceforge or OSDN.

Read on in the blog post

https://blog.dummzeuch.de/2019/06/09/gexperts-adds-copy-and-paste-for-delphi-tool-menu-entries/

2 hours ago, uligerhardt said:

clipboard format: Can't you just hand over the text?

Yes, I could.

36 minutes ago, OzTrev said:

I simply use:

 

 TOSVersion

I'm aware of TOSVersion, but it's simply not available in some of the Delphi versions I frequently use. As stated in the blog post, the method(s) described there even work(s) with Delphi 6.

28 minutes ago, Berocoder said:

I just wonder why not people using VmWare or similar virtualisation for Delphi?

In my case it's because I need access to specialized devices (cameras, lasers, GPSes ... some of it only available in one of our measuring vehicles) to develop and debug software that communicates with these devices. Most of that communication is time critical, so even if that device access could be virtualized, it would only get me so far (I can use remote desktop though, so I don't have to sit in the actual car.)

I tried to use the remote debugger, but it was not stable enough.

So I ended up installing Delphi on each of the controlling computers. Of course I ran into the installation limit frequently, because those computers just don't survive the conditions they are used in for much longer than 2 years (it's cheaper to frequently replace them rather than trying to protect them.) That's why I switched to a network named license last year. Much more convenient.

Of course that's not quite the typical use case for Delphi.

33 minutes ago, Berocoder said:

Then you never have to move to a new computer and this problem is gone.

Until Microsoft stops supporting your operating system and the corporate IT department tells you to upgrade, because your Windows XP/7/8 is a security risk.

And even if that does not happen, keeping several VMs up to date while maintaining backups quickly becomes a major chore. Even with multi terabyte hard disks it still takes time to copy them around.

1 hour ago, Sherlock said:

And perhaps don't switch the payment context to Europe (it's free anyway).

No, it still works when switching to Europe.

So the description for GetMemory in the online help is wrong: It does not raise an EOutOfMemory exception.

The Online Help says the following about GetMemory:

Quote

 

GetMemory allocates a memory block.

GetMemory allocates a block of the given Size on the heap, and returns the address of this memory. The bytes of the allocated buffer are not set to zero. To dispose of the buffer, use FreeMemory. If there is not enough memory available to allocate the block, an EOutOfMemory exception is raised.

If the memory needs to be zero-initialized, you can use AllocMem.

Note: GetMemory is the C++ compatible version of GetMem.

http://docwiki.embarcadero.com/Libraries/en/System.GetMemory

What exactly does it mean by "GetMemory is the C++ compatible version of GetMem."? What does GetMemory do that GetMem doesn't?

Why and when should I use GetMemory or GetMem?

This is the OLH for GetMem:

Quote

GetMem allocates a memory block.

GetMem allocates a block of the given Size on the heap, and returns the address of this memory in the P parameter. The bytes of the allocated buffer are not set to zero. To dispose of the buffer, use FreeMem. If there is not enough memory available to allocate the block, an EOutOfMemory exception is raised.

Note: If the memory block must be initialized with zero, you can use AllocMem.

This function is not available in C++. In C++ you can use GetMemory.

In case of a typed pointer, you should consider the New and Dispose procedures, which respectively initialize and finalize the memory block accordingly.

I can't see any difference.

Maybe it's just that one is available for C++ Builder programs, and the other isn't? So for Delphi programs it doesn't matter which to use?

What does the enter key do?

Depending on the usual workflow (does the user usually want to view the report? Or does he want to copy or send it somewhere?) one of the other buttons might be a good option.

Another frequently required information for further processing is the full file name, so maybe there should be a fourth button to copy it to the clipboard.

20 minutes ago, Mike Torrettinni said:

This is interesting. I would think when you create file you want 'success' message to appear.

That depends: A transient message is fine, a persistent one that I have to click to get rid of it, can be annoying. If it provides the additional options you propose, it might be less annoying. But that's a matter of taste.

OK, so my original translation was correct. Thanks everybody.

Regarding using Delphi enums:

typedef VmbUint32_t VmbPixelLayout_t;

is used in the function and struct declarations.

Yes, I could also change that too and use {$Z4} or {$MINENUMSIZE 4} to ensure that the enum size is at least 4 byte (but can I be sure that they aren't larger? (ever?)), but I'm not sure it's worth it. For now I'll simply go forward keeping it a Unit32, since I need something working as fast as possible.

4 hours ago, Remy Lebeau said:

4 hours ago, dummzeuch said:

Unfortunately that won't compile: Delphi does not allow duplicate values in these enums.

Embarcadero's documentation says otherwise

OK, maybe that changed in later versions. I'm sure I tried that and it didn't compile.

But all that is syntactic sugar. I need to know about the values of

8 hours ago, dummzeuch said:

 

VmbPixelLayoutYCbYCr422 and VmbPixelLayoutYCbCr444.

3 hours ago, uligerhardt said:

Couldn't you use a normal Delphi enum (i.e. without assignments) for the "main" values and define the extraneous ones as untyped constants?

No, the ordinal values must be correct. These numbers are passed as parameters to a DLL written in C.

1 hour ago, PeterBelow said:

Delphi actually supports C-style enums, although they are supposed to be used only in code that needs to interface with  C Dlls. The  compiler creates no RTTI for them, so they cannot be used in published properties, for instance. But this compiles without problem:

 

type
  VmbPixelLayout = (
    VmbPixelLayoutMono,
    VmbPixelLayoutMonoPacked,
    VmbPixelLayoutRaw,
    VmbPixelLayoutRawPacked,
    VmbPixelLayoutRGB,
    VmbPixelLayoutBGR,
    VmbPixelLayoutRGBA,
    VmbPixelLayoutBGRA,
    VmbPixelLayoutYUV411,
    VmbPixelLayoutYUV422,
    VmbPixelLayoutYUV444,
    VmbPixelLayoutMonoP,
    VmbPixelLayoutMonoPl,
    VmbPixelLayoutRawP,
    VmbPixelLayoutRawPl,
    VmbPixelLayoutYYCbYYCr411,
    VmbPixelLayoutCbYYCrYY411 = VmbPixelLayoutYUV411,
    VmbPixelLayoutYCbYCr422,
    VmbPixelLayoutCbYCrY422 = VmbPixelLayoutYUV422,
    VmbPixelLayoutYCbCr444,
    VmbPixelLayoutCbYCr444 = VmbPixelLayoutYUV444,

    VmbPixelLayoutLAST
    );

 

Unfortunately that won't compile: Delphi does not allow duplicate values in these enums.

Given the following C type definition:

/** image pixel layout information*/
typedef enum VmbPixelLayout
{
    VmbPixelLayoutMono,
    VmbPixelLayoutMonoPacked,
    VmbPixelLayoutRaw,
    VmbPixelLayoutRawPacked,
    VmbPixelLayoutRGB,
    VmbPixelLayoutBGR,
    VmbPixelLayoutRGBA,
    VmbPixelLayoutBGRA,
    VmbPixelLayoutYUV411,
    VmbPixelLayoutYUV422,
    VmbPixelLayoutYUV444,
    VmbPixelLayoutMonoP,
    VmbPixelLayoutMonoPl,
    VmbPixelLayoutRawP,
    VmbPixelLayoutRawPl,
    VmbPixelLayoutYYCbYYCr411,
    VmbPixelLayoutCbYYCrYY411 = VmbPixelLayoutYUV411,
    VmbPixelLayoutYCbYCr422,
    VmbPixelLayoutCbYCrY422 = VmbPixelLayoutYUV422,
    VmbPixelLayoutYCbCr444,
    VmbPixelLayoutCbYCr444 = VmbPixelLayoutYUV444,

    VmbPixelLayoutLAST,
}VmbPixelLayout;
typedef VmbUint32_t VmbPixelLayout_t;

Am I right in assuming that the following constants are an equivalent?

const
  VmbPixelLayoutMono = 0;
  VmbPixelLayoutMonoPacked = 1;
  VmbPixelLayoutRaw = 2;
  VmbPixelLayoutRawPacked = 3;
  VmbPixelLayoutRGB = 4;
  VmbPixelLayoutBGR = 5;
  VmbPixelLayoutRGBA = 6;
  VmbPixelLayoutBGRA = 7;
  VmbPixelLayoutYUV411 = 8;
  VmbPixelLayoutYUV422 = 9;
  VmbPixelLayoutYUV444 = 10;
  VmbPixelLayoutMonoP = 11;
  VmbPixelLayoutMonoPl = 12;
  VmbPixelLayoutRawP = 13;
  VmbPixelLayoutRawPl = 14;
  VmbPixelLayoutYYCbYYCr411 = 15;
  VmbPixelLayoutCbYYCrYY411 = VmbPixelLayoutYUV411;
  VmbPixelLayoutYCbYCr422 = 9; // is this correct?
  VmbPixelLayoutCbYCrY422 = VmbPixelLayoutYUV422;
  VmbPixelLayoutYCbCr444 = =10; // is this correct?
  VmbPixelLayoutCbYCr444 = VmbPixelLayoutYUV444;

I am in particular usure about the ones following those entries with an explicit value assignment, marked with the "// is this correct?" comment above.

I think that enums in C work like this:

typedef enum bla
{
zero, // start counting at 0
one, // 1
two, // 2
three, // 3
eins = one, // reset counter to 1
zwei, // 2
drei, // 3
}

So, every time a value is explicitly assigned to an enum the current counter is reset.

In case that matters: The declaration is from VmbTransformTypes.h, part of the Vimba ImagesTransform library for Microsoft Visual C(++).

8 hours ago, PeterPanettone said:

I  often write in uppercase without having the intention to shout.

Even if it's not your intention, it's still considered shouting, because nobody but you knows your intention.

Svn also works fine for Github repositories, as long as you don't try to commit or use externals. Also, pull requests don't work.

If I remember correctly, the URL is the same.

26 minutes ago, Ian Branch said:

There is a Delphi utility around somewhere that allows you to delete Delphi libraries/components, along with a lot of other Delphi related stuff, but I don't recall its name.

Other than that, I have nothing to offer.

You might be thinking of my KnownIdePackagesManager Tool for Delphi, but that only handles IDE packages, not component packages. It should be easy to exend it to do that too, though.

1 hour ago, PeterPanettone said:

Another approach would be using hardlinks. Would work with current search.

I'm afraid recursive hardlinks word result in an infinite loop right now.

7 hours ago, PeterPanettone said:

Thanks, CnWizards has a pretty good syntax colorizer, but there doesn't seem possible to colorize just Todo items:

 

As I said: It's proof that it could be done by a plugin. I didn't say it does it.

But you could get the source code and that functionality.

3 hours ago, PeterPanettone said:

Currently, ToDo items in the Code Editor have the same syntax color as comments:

 

If ToDo items had a separate syntax color, they would be better visible. This would be very useful!

 

What do you people think? Could this possibly be done by an IDE expert/add-in?

It could be done by a plugin, see the cnwizards advanced syntax highlighting. It may even already support it, I haven't checked.

My impression is that there are very few people left from the original Jedi group.

I know for sure that I personally stopped contributing when the project moved to Github, but my contributions were merely a few bug fixes, so they don't really count in the big picture.

The CPU sitting at 13% probably means that something is using one core at 100%. So I would not subscribe to this view:

4 hours ago, Ian Branch said:

There doesn't seem to be a lot happening as far as the PC itself is concerned, the CPU usage sits at around 12-13%.  See attached.

Have you tried to disable all IDE extensions to check whether it is caused by one of these?

Just in case anybody is still interested: I have changed the GExperts Convert Strings Editor Expert to allow for prefixes and suffixes for all lines.

Example:

I want to create a string containing this code:

function FindClassForm(const AClassName: string): TForm;
var
  i: Integer;
  s: string;
begin
  Result := nil;
  s := 'Some String';
  for i := 0 to Screen.FormCount - 1 do
    if Screen.Forms[i].ClassNameIs(AClassName) then begin
      Result := Screen.Forms[i];
      Break;
    end;
end;

Which means:

• Quote the lines and escape any existing quotes
• Add a variable assignment as prefix to the first line
• Add a "       " prefix to all lines to indent the whole thing
• add a " + #13#10" suffix to each line but the last
• add a ";" suffix to the last line.

The result looks like this:

s := 'function FindClassForm(const AClassName: string): TForm; ' + #13#10
      'var ' + #13#10
      '  i: Integer; ' + #13#10
      '  s: string; ' + #13#10
      'begin ' + #13#10
      '  Result := nil; ' + #13#10
      '  s := ''Some String''; ' + #13#10
      '  for i := 0 to Screen.FormCount - 1 do ' + #13#10
      '    if Screen.Forms[i].ClassNameIs(AClassName) then begin ' + #13#10
      '      Result := Screen.Forms[i]; ' + #13#10
      '      Break; ' + #13#10
      '    end; ' + #13#10
      'end; ';

There is no release for this yet, but you can always get the sources and compile your own dll:

https://blog.dummzeuch.de/gexperts-documentation/compiling-gexperts/