Leaderboard

Nobody really cares that much. It's a gruesome way to go. I'd solve the problem properly but you don't want to tell us what the problem is.

That is absolutely the wrong thing to do. There is no such concept as a "null iterator" in the standard library. An iterator has to always point at something valid, whether it is the 1st item in a container/range, the end of a container/range, or anything in between. For what you are attempting, you would need to wrap the iterator inside a std::optional (or equivalent, like Roger Cigol suggested), eg: std::optional<std::list<MyType*>::const_iterator> mp1MyType; void MyTypes::first() { mp1MyType = std::nullopt(); } bool MyTypes::next() { if ( !mp1MyType.has_value() ) mp1MyType = mLstMyTypes.begin(); else ++(*mp1MyType); if ( *mp1MyType == mLstMyTypes.end() ) { mp1MyType = std::nullopt(); return false; } return true; } MyType* MyTypes::getPresent() const { return mp1MyType.has_value() ? *(*mp1MyType) : nullptr; } But, why are you waiting until next() is called to move the iterator to the 1st item? Why can't you do it in first() instead? Seems like first() should return a bool indicating whether the iterator is valid, just like next() does, eg: std::list<MyType*>::const_iterator mp1MyType; bool MyTypes::first() { mp1MyType = mLstMyTypes.begin(); return ( mp1MyType != mLstMyTypes.end() ); } bool MyTypes::next() { if ( mp1MyType != mLstMyTypes.end() ) { ++mp1MyType; if ( mp1MyType != mLstMyTypes.end() ) return true; } return false; } MyType* MyTypes::getPresent() const { return ( mp1MyType != mLstMyTypes.end() ) ? *mp1MyType : nullptr; }

I'm slowly adding TBytes versions of binary methods and properties as I update components, should be added in the next week or so. Angus

You are. The working set are the pages of a process' virtual memory that resides in physical memory. They are there because the process has a need for them to be there (e.g. it has referenced an address in virtual memory causing a working set page to be mapped to that address). If something else in the system has a need for physical memory, and it's all in use (which, by design, is normally is - because why not) then the least recently used pages will be paged out and eventually written to the page file, so the physical page can be mapped to the other process' working set. The above is just a simplification of the virtual memory management but the point is that, unless what you are doing is really extreme, then you don't have to think about it; It just magically works. I know everybody has to go through the phase of thinking that they can outsmart the OS virtual memory management by messing with the working set but you really should leave it alone. The OS virtual memory system was designed 50 years ago by people who actually knew what they were doing. You might very well be having memory issues but look to the memory manager instead. The working set isn't the problem.

MsgDlgIcons[TMsgDlgType.mtInformation]:=TMsgDlgIcon.mdiInformation; MessageDlg('Exiting the Delphi application.', mtInformation, [mbOk], 0, mbOk); You have to System.UITypes into the uses.