On Sunday, December 15, 2013 7:05 PM [GMT+1=CET],
François Piette wrote:

>>> While busy at porting ICS to Android, I had the need of replacing
>>> Windows custom messages by something else which is portable across
>>> Windows and Android.
>> Your PostMessage() doesn't take a window handle and seems to be a
>> class 
> method, how is that helpful to port existing code?
> It is useful for posting custom messages to a TForm. That's why there
> is no window handle. TMessagingSystem instance is tied to a form (A
> FireMonkey form by the way).

And how about console applications which do not have a form?
With my implementation you are able to create a 'window handle' as the message 
target in OS X as you are used to in Windows, in a thread or a console 
application or the main GUI thread just as you like.    

> You pass the instance reference to who
> must post a message to the form. In the case of the demo program, it
> is a thread. A window handle cannot be used because it doesn't exist
> in Android. 

Window handles do not exist in OS X too but that can be emulated as I showed in 
ICSv8. The nature of PostMessage() and SendMessage() is that they take a target 
(call it handle). I emulated Windows' messaging as close as possible as it is 
needed to be able to run ICS with minimal changes. TIcsMessagePump implements 
the message pump (a thread-local singleton).

> Passing an object instance is valid for all operating
> system. That object is crafted for the given operating system and his
> interface is the same for all operating system.
> For non visual components, there is another code under development.
> You have access to the repository and you can have a look at it's
> current state. 

Will your port introduce a new incompatible source branch as it was the case 
with your Kylix port in the past? 

> The difficult to port ICSv8 to Android isn't the messaging but the
>> lack of AnsiString 
> I already wrote an AnsiString class which does the required work.

I saw it, that's far away from solving the problem! 
>> and ARCed objects as well as zero-based strings.
> ARC is much less an issue than I had expected. You can still mostly
> program like you have always done. The compiler replace your calls to
> Free and FreeAndNil by what is required when ARC is in action. The
> [weak] attribute is simply ignored when there is no ARC.

Let's see and count the memory leaks and other issues caused by ARC-ed objects 
over the next years in your ported ICS source code. You will likely introduce 
bugs that are difficult to debug, EMBT itself is not able to prevent that in 
their own code since some releases now. 

> Same for zero-based strings. This require some code reviews and
> changes but the result can be made backward compatible.
> Resistance to change is a well-known issue in HR management :-)

Well, zero-based strings is a complety unnecessary mess IMO.


To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to