Jump to content

stijnsanders

Members
  • Content Count

    116
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by stijnsanders


  1. No, not al all. Remember a few decades ago, when most personal computers had only one processor? We had multiple threads then, the operating system cycles them for you nicely, even over the several processors if your system has more.

    If you're running really intensive work in the threads, you may cause slowdowns by having more threads than processors (it's interesting to learn about thread affinity as well), but as soon as you're doing I/O from these threads (and the system handles device calls on your threads) you may get an increase of total performance, because the system can let more threads work while some threads are 'waiting'.

    There's more to the story when you're using completion ports, or do overlapped IO calls... But only remotely related to your question about threads.

    • Like 2

  2. Looks like normal behaviour like you describe it: Windows will 'white out' applications and show them as non-responsive, when they stop reading messages from the message queue. In Delphi applications, there are two main ways to solve this: either call Application.ProcessMessages from time to time from the code that does the processing. There's some special care you'll need to take for the case when the user wants to abort the importing, or close the application. This will 'unfreeze' the application, because messages get handled, but may slow down the importing a little.
    The second way is to write the importing code so it uses background threads. There are libraries and solutions that can help you with this, or the hard way is inheriting from TThread yourself, but then you need to know how to synchronize between the main thread to output progress and results from the importing.


  3. If you really really need to do the work on the main thread (Are you really really sure?) I would consider doing the bind and accept calls on a separate thread. It will open and accept incoming connections, so Windows gets the correct inputs and knows you still intend to work through incoming requests eventually. Do read all about thread locking and critical sections first, as you'll need it to pass requests to and from a background thread.

    What I would also consider, is having the work done on a main thread of a separate instance of a separate exe-file, and do CreateProcess for each incoming request. It may look like a lot of work, but will solve the 'main thread problem' and allow to handle multiple requests at once.


  4. If you are willing to consider one more alternative, I've been working on a solution to use the power and speed of the Delphi compiler for web projects, but specifically in a non-RAD way, that is without form designers: https://github.com/stijnsanders/xxm

    It is mostly based on my previous experience on (old!) web-projects based on PHP, (old!) ASP and Cold Fusion, so — coming from React — you may find it lacking on the side of client-side support and scripting. But it's not impossible. It should offer a great platform to develop frameworks in any which way you want (React, Vue, Wordpress, Rails etc. are also based on JavaScript, PHP, Ruby etc.)

    If you're willing to investigate an existing xxm-based web-project, look here: https://github.com/stijnsanders/tx#tx

    Since React (and others) are based on keeping a server-side copy of the view and updating the client with changes to the DOM, I was planning on trying to create a proof-of-concept to show that this is also possible with xxm, but haven't gotten around to it. I've also come to think it may have been a bad choice to build the base interface (IXxmContext) on the COM sub-system, so I might also start an 'xxm v2.0', but currently I've got more plans than I can make time to make them work...
    If you would take a look, please let me know what you find...


  5. What is the exact variable type of ExcelApplication and ExcelWorkbook?

    I would guess Variant or OleVariant, and in that case, a technique called "late binding" is used. It both explains why you don't have code-completion, and that the code compiles even without the compiler knowing about the specific available properties and methods. Behind the scenes, the operations you do (Cells, Select and Save in this case) are resolved at runtime on the 'living' objects using hidden 'IDispatch' interfaces that list the available properties and methods by name. It was invented by Microsoft to make dynamic scripting languages work (like VBScript, and actually also something called "JScript" because they weren't allowed to call it JavaScript, but that's another story). And Delphi has excellent support for this (but a downside is it works so good you don't see anything of it and can't access it, need to get the sequence of calls exactly right and need to debug on live objects.)

    • Thanks 1

  6. So much code! Are you willing to try out a different JSON solution? When I was writing my very bare-bones connector to MongoDB, I was really into the Variant type, and really disliked long lists of overloads for all of the types. So I created my own JSON solution, that heavily uses the Variant type, and offers a really concise syntax. The above would look like this:

    JSON(['registration_ids',VarArrayOf(['crX...']),'notification',JSON(['title','Hi','body','Notification test'])])

     


  7. I think I've come across the things you describe when creating xxm. There's more to the project than REST, but to have an out-of-the-box option of hosting web projects created with xxm, I created a really basic HTTP server, that also handles multipart file uploads. So, if you have a web form like this that would allow a user to post a file, the server would process the parts of the request into specific parameters like this. But I'm afraid this is quite an integrated solution and not quite a 'snippet' you can use to apply elsewhere. None-the-less I warmly invite you to take a good look at xxm and see if it could be a fit for any project you're considering that combines Delphi and the web.


  8. I see in System.pas that VAnsiString is of type pointer and not of type AnsiString. I'm not sure you can 'just' cast it into type AnsiString (which happens to also be a pointer internally), but assuming you can:

    SizeOf(VAnsiString)

    will probably always be 4 (on 32-bits, 8 on 64-bits), I guess you'll need

    Length(AnsiString(VAnsiString))

    then

    Move(AnsiString(VAnsiString),

    ... will actually read the pointer value (and whatever happens to be in memory after that) not the string data itself.

    You have to dereference, either explicitly:

    Move(VAnsiString^,

    ... or I prefer to do this as if I'm letting Move know where the start of the string data is:

    Move(AnsiString(VAnsiString)[1],

    ...

    And you use SizeOf for the Inc again, change that to Length, of better still use an extra local variable so you only need 1 call to Length (and the compiler can optimize register allocation for it)


  9. If you're willing to examine an alternative, and if you're struggling with other JSON solutions that appear to 'bind' the JSON data to some sort of schema that determine the full extent of what you'd possibly do with the date, check out this JSON unit I've created in the margin of an attempt at a no-frills MongoDB connector: https://github.com/stijnsanders/jsonDoc#jsondoc

    I also dislike solutions that depend long lists of overloads for all kinds of types, so it depends on Variants heavily, especially that a Variant value can hold a reference to the interface of a live instance if anything, such as another IJSONDocument object.

    Also arrays in JSON are converted to and from Variant arrays. So using VarType, you could detect when data is an array or not, if it's an sub-object, you'll get varUnknown, look at the function JSON declared in the unit how to get a IJSONDocument reference.

    Also have a look at function JSONEnum to list the "sectionX" fields the base object might have.

     


  10. I would humbly like to offer another alternative. By no means I want to imply it is any better than the other options of building a website with Delphi, but if you're willing to not use the RAD-side of Delphi, and its IDE, but want to use the Delphi language and its compiler, and combine HTML and server-side logic code in the same files much like (early!) PHP or Cold Fusion, I've created this solution to do just that: https://github.com/stijnsanders/xxm#xxm

    What I wanted was a way to create a website by working on the code, press F5 in a browser to put it to work, but have the website itself run from a freshly compiled DLL, from a Delphi project. This same DLL would use a generic interface, so by moving it from your development machine to a online web-server, you could use the same DLL with Apache httpd, IIS, or SCGI.

    It may take some work to get it going and set it up, and you don't have any support of a platform, but if you know what you're doing, that can be a good thing. Most other web-platforms I've witnessed all take some freedom away by the choices that have been made in their design, and you inevitably will hit these limitations later when you're trying to do something the platform wouldn't support.

    If you're interested to see a fully developed web-application on xxm, have a look here: https://github.com/stijnsanders/tx#tx

    (I once made "get started" tutorial, but should really update it, replace xxmLocal with xxmHttp and IE with Firefox or Chrome...)

    • Like 1
×