Jump to content

Ondrej Kelle

Members
 View Profile  See their activity

  • Content Count

    83

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Ondrej Kelle

  1. Posted · Edited by Ondrej Kelle

    I've checked it with Delphi XE. The declaration of TMenuBarInfo in Windows unit seems to be wrong (packed record, 29 bytes). Simply redeclare it in your unit:

      

    type
  {$A8} // default quadword-alignment
  PMenuBarInfo = ^TMenuBarInfo;
  tagMENUBARINFO = record
    cbSize: DWORD;
    rcBar: TRect;
    hMenu: HMENU;
    hwndMenu: HWND;
    { fBarFocused:1: BOOL;} { bar, popup has the focus }
    { fFocused:1: BOOL; }  { item has the focus }
    FocusedBits: BYTE;
  end;
  TMenuBarInfo = tagMENUBARINFO;

function GetMenuBarInfo(hend: HWND; idObject, idItem: Longint;
  var pmbi: TMenuBarInfo): BOOL; stdcall; external user32 name 'GetMenuBarInfo';

     

    which makes  the record size 32 bytes, then it works:

     

    menuitemrect.png

     

    BTW, it's already fixed in Rio.

     

    • Like 1

  4. Posted · Edited by Ondrej Kelle

    GetMenuBarInfo API should help.

     

    I have no Delphi at hand at the moment but the following quick test works in Lazarus: 

    
function GetWindowMenuItemRect(Handle: THandle; Index: Integer): TRect;
var
  Info: MENUBARINFO;
begin
  FillChar(Info, SizeOf(Info), 0);
  Info.cbSize := SizeOf(Info);
  Win32Check(GetMenuBarInfo(Handle, $FFFFFFFD, Index, @Info));
  Result := Info.rcBar;
end;

function GetScreenCanvas: TCanvas;
begin
  Result := TCanvas.Create;
  try
    Result.Handle := GetDC(0);
    Result.Pen.Style := psSolid;
    Result.Pen.Color := clRed;
    Result.Brush.Style := bsClear;
  except
    Result.Free;
    raise;
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  C: TCanvas;
  I: Integer;
begin
  C := GetScreenCanvas;
  try
    for I := 0 to MainMenu1.Items.Count - 1 do
      C.Rectangle(GetWindowMenuItemRect(Handle, I + 1));
  finally
    C.Free;
  end;
end;

     

    windowmenuitemrect.png

  5. Posted

    2 hours ago, Rollo62 said:

    I considered Node as a small excutable wrapper (a main loop if you will) around the V8 engine, and all the rest done by additional JS modules.

    There's a lot implemented natively: 

    C:\>node --version
v11.0.0

C:\>node
> require('module').builtinModules
[ 'async_hooks',
  'assert',
  'buffer',
  'child_process',
  'console',
  'constants',
  'crypto',
  'cluster',
  'dgram',
  'dns',
  'domain',
  'events',
  'fs',
  'http',
  'http2',
  '_http_agent',
  '_http_client',
  '_http_common',
  '_http_incoming',
  '_http_outgoing',
  '_http_server',
  'https',
  'inspector',
  'module',
  'net',
  'os',
  'path',
  'perf_hooks',
  'process',
  'punycode',
  'querystring',
  'readline',
  'repl',
  'stream',
  '_stream_readable',
  '_stream_writable',
  '_stream_duplex',
  '_stream_transform',
  '_stream_passthrough',
  '_stream_wrap',
  'string_decoder',
  'sys',
  'timers',
  'tls',
  '_tls_common',
  '_tls_wrap',
  'trace_events',
  'tty',
  'url',
  'util',
  'v8',
  'vm',
  'zlib',
  'v8/tools/splaytree',
  'v8/tools/codemap',
  'v8/tools/consarray',
  'v8/tools/csvparser',
  'v8/tools/profile',
  'v8/tools/profile_view',
  'v8/tools/logreader',
  'v8/tools/arguments',
  'v8/tools/tickprocessor',
  'v8/tools/SourceMap',
  'v8/tools/tickprocessor-driver',
  'node-inspect/lib/_inspect',
  'node-inspect/lib/internal/inspect_client',
  'node-inspect/lib/internal/inspect_repl' ]
>

    I believe (most of) those things are compiled and linked directly into Node executable as native code.

    2 hours ago, Rollo62 said:

    the question would be if there is any advantage of such ChakraCode-Node over V8-Node ?

    I'm not sure. It does seem like a lot of work.

     

  6. Posted

    ChakraCore is a Javascript (and WebAssembly) engine, comparable to Google's V8, Mozilla's SpiderMonkey or other similar implementations.

     

    Node.js is much more - a runtime host environment (native executable for the target platform) embedding V8, it implements some (native code) services and exposes them to the engine through an API. For example, you can instantiate a simple web server from Javascript run by Node as described here.

     

    There's also Node.js on ChakraCore, a fork of Node, using ChakraCore instead of V8 (by providing a V8 API shim layer and delegating to the ChakraCore engine).

     

    Node comes with a huge online ecosystem of Javascript modules and a package manager (npm) to manage the dependencies.

    Node modules can reuse other modules through an established ("require") method - you could think of it as Node's runtime equivalent of Delphi's "uses" clause in Javascript.

     

    My example shows a way to implement this "require" mechanism in a Delphi or Free Pascal host application, reading npm's "package.json" files where the module metadata is declared and resolving the "require" clauses to full-path file names so they can be loaded and evaluated at runtime with ChakraCore. It doesn't provide any of Node's extra services, so modules relying on them won't work. For example, an attempt to call require('http'); from a script will raise an exception since my host application doesn't provide the "http" module and the implementation of its API (which could be done with some extra work, e.g. using Indy).

     

    A hint on how one might provide those services to the engine can be found in the NodeProcess unit which is an incomplete stub implementation of the 'process' module (I just wanted to satisfy graphql for the demo).

    • Like 1

  7. Posted

    https://tondrej.blogspot.com/2019/01/node-modules-with-delphi-and-free-pascal.html

     

    chakracore-delphi now comes with NodeSample, a new sample console application showing (as of now very limited) support for Node modules. Included are:

     

    - commonmark
    - graphql
    - json-query
    - lodash
    - moment

     

    The sample only shows how Node modules can be resolved and used in Delphi and Free Pascal applications. It doesn't implement Node's event loop or any of its internal modules or native bindings like path, fs or http; any scripts referencing them will - for now - raise an exception.

     

    Screencast (YouTube)

    • Like 1

  9. Posted

    1 hour ago, Rollo62 said:

    Thanks for the nice project.

    Sorry, I don't want to be negative, but do you know more about the future of ChakraCore ?

    Since Edge browser has moved to Chromium, this is probably a not too bright future.
    I would not try to launch big projects based on ChakraCore any longer.

    Thanks, I'm glad you like it.

     

    Of course, what the move to Chromium really means in practice remains to be seen.

     

    For now, ChakraCore still seems to be active, with bug fixes and new features, too. Quoting from their statement:

    Quote

    ChakraCore is currently being used in various projects outside the browser. So, despite the change of direction for Microsoft Edge, our team will continue supporting ChakraCore. We will ensure that any security vulnerability is patched in a timely manner, apart from bringing other enhancements to the engine. The project will also continue taking public contributions.

     

    As far as I know, ChakraCore is used in:

     

    Node-ChakraCore (e.g. also on Windows 10 IoT Core)

    Azure DocumentDb (not sure about CosmosDb)

    Outlook.com

    Cortana

    Minecraft scripting API

    Sphere game engine

    Reference FHIR server

  15. Posted · Edited by Ondrej Kelle

    The scope of a forward declaration is the type declaration section (typically the unit, or the enclosing type declaration section of a nested class). If the classes directly reference each other you'll have to put them in the same declaration section (unit or enclosing type).

    There are workarounds, depending on what you need. For example, you could reference a generic ancestor (e.g. TTestBase, or even TObject) in the interface section, and typecast to the actual class in implementation, or use polymorphism. Circular unit references in the implementation section are allowed.

×