IF nIdx < THIS^.nLastIdx THEN
    Tc2_System.MEMCPY(destAddr := pTmp,
                      srcAddr := ADR(pBuffer[nIdx + 1]),
                      n := TO_UDINT(THIS^.nLastIdx - nIdx)*THIS^.nItemSize);
END_IF

At line 15, the statement destAddr := pTmp is actually incorrect, this time pTmp should start from an offset whose size is equivalent to the previously copied memory.

At the moment observables always notify their observers upon write-access to its value. That might be taxing if there is cyclical write-access to an observable with many observers.

Observable's properties like bAutoNotify and bNotifyWhenChanged can default to a specific value configurable via a parameter list.

Cache the PLC repository information, to which the library is installed, at the end of chocolateyInstall.ps1 so that chocolateyUninstall.ps1 can read that information and uninstall the library from the correct repository.

1. Consider breaking down the current FB_List_Test test suite into multiple test suites each dedicated to testing a single method/property
2. Add more tests. Test ruthlessly, so that bugs like #24 won't happen again

Check more in Stefan's blog at: https://stefanhenneken.net/2016/12/07/iec-61131-3-the-command-pattern/
Commands can be abstracted to a few types, like on/off, integer, or float, for example.

Figure out some auto doc generator for the API based on, for example, comments, or pragmas written inside the source code

At the moment FB_Objects are able to be bound together via its FB_init "constructor". This property has been taken directly from TcOpen. For their (TcOpenGroup) use-case, objects are instantiated within a context, which has "global" shared resources for all the child objects to access. For instance, a TcoLogger within a context is available for all child objects to use. Here are a few points to mull over:

1. What are the real benefits of this practice (for our use case)?
2. Does this increases unnecessary and accidental couplings between objects?
3. Should this be the default behaviour for FB_Object? If not, should there be another object like FB_LinkedObject? Hence the final implementation would include FB_Object (resembling current FB_OrphanObject) and FB_LinkedObjects (resembling current FB_Object)

Does @Colho have any thoughts on this?

Perhaps this sounds more "natural"?

Dictionary as a new Collection type would be beneficial, as dictionary is a widely used data structure. Basic idea is to have <Key, Value> pair, where a key is always associated with a value.

Dictionary characteristics:

• Key and value pairs can be added to the dictionary
• Key and value pairs can be removed from the dictionary
• Values can be fetched from the dictionary with a key
• Every key in dictionary must be unique
• Keys can be tested are they already in the dictionary

Some remarks:

• Using hash table for fast value lookup?
• Possibility to enumerate all the key and value pairs? (for looping through the dict?)
• Equality comparer for generic objects?

Small typo on yellow

Originally posted by @Colho in #5 (comment)

Refactor observer pattern to use the new FB_List implemented from #3

Adding an item to the list can be optimized by resizing the list more than needed, reducing the time taken to add.
For deleting an item, consider removing that item alone and leaving the memory area the same most of the time. Only when the spare memory exceeds a certain threshold does the list resize.

Keep in mind that the interlock module should make the interlock reasons visible enough for debugging purposes

... to avoid polluting the list of observers and memory waste.

Hello,
create a usage example to understand how to use it.