On 09:31 AM, Paul Breneman wrote: >On 02:32 AM, Bob Axtell wrote: >>This newbie is familiar with COMPORT from WINSOFT from my olden Delphi >>Instant Photo Artist Download. days, but I can no longer afford it for one program. >>>>Does anybody know of a free/cheap component?

Any how does it install? >>www.CtrlTerm.com uses Synapse and Synaser and there is a port for Lazarus. I should have mentioned that www.CtrlTerm.com is a simple example of how Synapse and Synaser can be used (it is not the component itself). Best regards, Paul www.TurboControl.com -- _______________________________________________ Lazarus mailing list.

On 10:53 PM, Roberto P. Wrote: >I'd like to point out that CPortLaz is multithreaded Does it work similar to AsyncPro? In fact, IMHO, it would be desirable to have a component that _internally_ uses TThread to handle blocking ports (either using just a byte-FIDO - this is what AsyncPro does - and/or allowing the user to implement a protocol within the Thread's 'Execute' ), and when some information from the port is received (at least one byte or when the protocol handler issues a 'ready'), does an Event (aka queued callback) to the main thread. The main thread call of course needs to be 'scheduled' using means such as TThread.Queue or Application.QueueAsyncCall. (As at the time when AsyncPro was released, Delphi did not provide either, AsyncPro uses Windows Messages by directly accessing the Windows API, which happily is not necessary with Lazarus). Unfortunately Thread ->Mainthread signaling is only easily provided in Lazarus in the GUI based Widget Types. (NoGUI still needs an appropriate enhancement.) But of course the user (or even a ComPort Unit) could provide a usable Main Loop implementation. La Scienza Del Natural Bodybuilding Over 50.

The malicious script created a user account, disabled the host-based firewall, and globally opened port 3389 for Remote Desktop Protocol (RDP) access.

-Michael -- _______________________________________________ Lazarus mailing list. On 10:53 PM, Roberto P. Wrote: I'd like to point out that CPortLaz is multithreaded Does it work similar to AsyncPro? In fact, IMHO, it would be desirable to have a component that _internally_ uses TThread to handle blocking ports (either using just a byte-FIDO - this is what AsyncPro does - and/or allowing the user to implement a protocol within the Thread's 'Execute' ), and when some information from the port is received (at least one byte or when the protocol handler issues a 'ready'), does an Event (aka queued callback) to the main thread.

The main thread call of course needs to be 'scheduled' using means such as TThread.Queue or Application.QueueAsyncCall. (As at the time when AsyncPro was released, Delphi did not provide either, AsyncPro uses Windows Messages by directly accessing the Windows API, which happily is not necessary with Lazarus). Unfortunately Thread ->Mainthread signaling is only easily provided in Lazarus in the GUI based Widget Types. (NoGUI still needs an appropriate enhancement.) But of course the user (or even a ComPort Unit) could provide a usable Main Loop implementation. Michael Schnell wrote: >On 10:53 PM, Roberto P.

Wrote: >>I'd like to point out that CPortLaz is multithreaded >>Does it work similar to AsyncPro? >>In fact, IMHO, it would be desirable to have a component that >_internally_ uses TThread to handle blocking ports (either using just a >byte-FIDO - this is what AsyncPro does - and/or allowing the user to I agree. My mods to serial.pp were accepted into trunk a few weeks ago, but that is explicitly unthreaded since it's intended as the lowest layer for cases where- as an example- timestamps or changes to physical control lines need to be enqueued with the character stream. >implement a protocol within the Thread's 'Execute' ), and when some >information from the port is received (at least one byte or when the >protocol handler issues a 'ready'), does an Event (aka queued callback) >to the main thread.

With the caveat that this sort of thing needs to be implemented very carefully so that it can interwork with e.g. A terminal emulator component. I think the two would need to be designed together, even if in practice one was coded first. Until then, FPC's thread handling is sufficiently good that an application-specific hack isn't particularly difficult. -- Mark Morgan Lloyd markMLl.AT. Uk [Opinions above are the author's, not those of his employers or colleagues] -- _______________________________________________ Lazarus mailing list.

Op 06-05-14 21:08, Zaher Dirkey schreef: >Try >>>>Hi, Out of curiosity I looked into this, and I downloaded the source from sourceforge. Trying to install I found problems: minicommons never compiled for fpc/lazarus? Because some function declarations are different from the forward declarations. Solved this for now by making them identical. More problematic: minilib lacks HTMLKeywords.inc. There I'm stuck.

I would like to try the pos-library. -- _______________________________________________ Lazarus mailing list. On Thu, May 8, 2014 at 10:37 PM, Koenraad Lelong wrote: op 06-05-14 21:08, Zaher Dirkey schreef: Try Hi, Out of curiosity I looked into this, and I downloaded the source from sourceforge.

Trying to install I found problems: minicommons never compiled for fpc/lazarus? Because some function declarations are different from the forward declarations. Solved this for now by making them identical. More problematic: minilib lacks HTMLKeywords.inc. There I'm stuck. I would like to try the pos-library. -- ______________________________ _________________ Lazarus mailing list.

Never mind those functions. I later read that I needed to use release, in stead of trunk. There all was OK. I will try again ASAP.

I spoke a bit too soon. I downloaded release (download snapshot). Then I tried to compile lib/minicommons.

I spoke a bit too soon. I downloaded release (download snapshot). Then I tried to compile lib/minicommons. I get the same errors I had before: /lib/mnFields.pas(750,20) Error: Calling convention doesn't match forward /lib/mnFields.pas(213,14) Hint: Found declaration: TmnFields.QueryInterface(constref TGuid,out ):LongInt; CDecl; /lib/mnFields.pas(798,20) Error: Calling convention doesn't match forward /lib/mnFields.pas(205,14) Hint: Found declaration: TmnFields._AddRef:LongInt; CDecl; /lib/mnFields.pas(803,20) Error: Calling convention doesn't match forward /lib/mnFields.pas(206,14) Hint: Found declaration: TmnFields._Release:LongInt; CDecl.