The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,232 other followers

Archive for the ‘Development’ Category

Delphi debugging tip: keep an eye on a object field of an object that will go out of scope eventually

Posted by jpluimers on 2021/01/26

Every once in a while you want to have a Delphi Watch of a field inside an object (say an object of type TContext), except that the field has no value yet, but eventually will point to another object (say an object of type TUser).

However, the original object will go out of scope, so you need to employ a few tricks.

First of all, you get the address of that field:

@(Context().FCurrentUser) = $7EF6F624

Then you watch the content of that field:

TUser(PPointer($7EF6F624)^),r = nil

To get to this trick, you have to remember:

  1. The contents of address $7EF6F624 is pointer (at first nil) to a TUser.
  2. You get to the contents of the address $7EF6F624 by using PPointer($7EF6F624)^.
  3. Then you cast it to the object you want with the TUser(...) cast.

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

Thought experiments can help you solve a problem early

Posted by jpluimers on 2021/01/21

Important logical principle to take away from [WayBack] The dialog manager, part 2: Creating the frame window – The Old New Thing:

If you’re not sure whether something is true, ask yourself, “What would the world be like if it were true?” If you find a logical consequence that is obviously wrong, then you have just proven [by contradiction] that the thing you’re considering is indeed not true.

Thought experiments like these can really help you get a feel for parts of a problem before you completely resolve the full problem.

Related: Thought experiment – Wikipedia

–jeroen

Posted in Development, LifeHacker, Power User, science, Software Development | Leave a Comment »

Default XML encoding is UTF-8 (or better: utf-8). If it contains other byte sequences, this is an error.

Posted by jpluimers on 2021/01/21

I should have had the below answer when writing about StUF – receiving data from a provider where UTF-8 is in fact ISO-8859.

A while ago, a co-worker did not believe when I told that default XML encoding really is UTF-8 (and tried to force it to utf-8), and that if the content had byte sequences different from the (either specified or default) encoding, it was a problem.

I though I blogged about the default, and where to find it, but apparently, I did not.

My blog had (and has <g>) a truckload of articles mentioning UTF-8, less articles containing UTF-8, encoding and xml, but the ones having UTF-8, default, encoding and xml did not actually tell about a standard that really defines XML uses UTF-8 as default encoding when there is no other encoding information – like BOM (byte order mark), HTTP, or MIME encoding) available.

W3C indeed specifies it. [WayBack] utf 8 – How default is the default encoding (UTF-8) in the XML Declaration? – Stack Overflow has a summary (thanks James Holderness!):

The Short Answer

Under the very specific circumstances of a UTF-8 encoded document with no external encoding information (which I understand from the comments is what you’re interested in), there is no difference between the two declarations.

The long answer is far more interesting though.

and an elaboration:

Read the rest of this entry »

Posted in Development, Encoding, Software Development, UTF-8, UTF8, XML, XML/XSD | Leave a Comment »

If you use an implementation of TNonRefCountInterfacedObject, then document in the descendants how lifetime management is arranged for

Posted by jpluimers on 2021/01/21

There are a few TNonRefCountInterfacedObject (or maybe better named TNonReferenceCountedInterfacedObject) implementations around (see list of links below).

They can be used to expose interfaces, but do not provide interface reference counting. This means you have to do your own lifetime management, which can bring quite a few headaches.

So each class you descend from it must have proper motivation on why, and how lifetime management is performed.

One thing you can do is mark the class with a hint directive like [WayBack] library.

In addition, [Archive.is] TNonRefCountInterfacedObject / [Archive.is] TNonReferenceCountedInterfacedObject implementations should at least implement [WayBack] IInterface (or [WayBack] IUnknown in really old Delphi versions); I have seen implementations that don’t but just provide almost empty [WayBackQueryInterface, [WayBack] _AddRef and [WayBack] _Release methods).

Some examples via  “TNonRefCountInterfacedObject” – Google Search:

Delphi RTL/VLC/FMX

I used this GExperts Grep Search expression to find the entries below: (_AddRef|_Release|QueryInterface)

Delphi itself has a few implementations of non-standard interface management that have good documentation on their use cases. So take a look at at least these before doing something odd with interface implementations yourself:

  • [WayBack] TAggregatedObject in System
    • This redirects all IInterface implementations to a controller
    • It does not implement IInterface itself, so a descendent must add the interface reference
    • Descendants are TContainedObject and TPropertyPageImpl (the latter used by TActiveXPropertyPage)
  • [WayBack] TContainedObject in System
    • This redirects all IInterface implementations except QueryInterface to a controller
    • Descendants are for instance TSOAPHeaders (via TSOAPHeadersBase) used by TSoapPascalInvoker, TInvokableClass and TRIO, and TConnectionPoint used by TConnectionPoints
  • [WayBack] TInterfacedPersistent in System.Classes
    • This supports the notion of (potentially) being owned by another TPersistent. Classes like TCollectionItem, TFieldOptions and TEditButton implement this ownership behaviour.
    • When owned, then redirect reference counting to the owner (if that owner implements IInterface), but not QueryInterface
    • When not owned, then it is effectively non-reference counted
  • [WayBack] TComponent in System.Classes
    • This supports the notion of (potentially) being owned by another TComponent. Classes like TComponent and TCollectionItem implement this ownership behaviour.
    • When owned, then redirects all IInterface calls to the owner (including QueryInterface).
  • [Archive.is] TXPEditReaderStream in DUnit XP_OTAEditorUtils. It is largely undocumented.
  • TXPInterfacedObject in DUnit XPInterfacedObject. It is largely undocumented too.

Not so good examples:

  • [WayBack] TCustomVariantType in System.Variants (which is basically TSingletonImplementation with a lot of extra methods)
  • [WayBack] TSingletonImplementation in System.Generics.Defaults(which is basically what most TNonRefCountInterfacedObject implementations do; this is sort of OK as it is meant to be used only in [WayBack] TCustomComparer<T> and descendants that are supposed to be singletons).
  • IUnknown in Winapi.Ole2 (this whole unit is undocumented; the class only has virtual abstract methods; the unit – together with Winapi.OleCtl – seems to be only meant to support the depcrecated Vcl.OleAuto unit.)

And of course there is the standard implementation with proper multi-threading support:

There are quite a few classes that implement reference counting while descending from things like TComponent, usually without the proper multi-threading support that TInferfacedObject has:

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

Don’t use global state to manage a local problem – The Old New Thing

Posted by jpluimers on 2021/01/20

The 20081211 article [WayBack] Don’t use global state to manage a local problem – The Old New Thing reminds me of a process I went through with a programming team a few years ago.

A lot of their source base came from the procedural era: global variables and global methods. No classes. No methods on records.

Taking them to the level of reference counted immutable instances that used dependency injection as an architectural design was a long journey.

Early in their journey, they would create a lot of methods on classes and records at the class level.

Then they started introducing instances that were basically singletons.

Finally they made real instances that could have more than one available at run-time. These would still create other instances when they needed, often through a few singletons that were still left (for instance session state, database connection state, etc).

Then they introduced caches and pools to keep things alive longer than as to speed up things. It also highly complicated life-time management.

Finally they backed down, and started hooking up things through dependency injection.

A lot of the above caused global state to be used for solving local problems.

It was a tough, but fun time, to get them on the right path, tickling them with the right puzzles at the right time to steer them through their journey..

–jeroen

Posted in Conference Topics, Conferences, Development, Event, Software Development | Leave a Comment »

 
%d bloggers like this: