David, we must have posted exactly same time O_0.Ok...i will have a look at your examples.I think if this could work it would be fantastic becauseas it is now, training this Friend via the chat from China to Australiaworks REALLY well..i use it everyday, but sometimes i need to take a quick screen grab ofwhat he's working on and have it popup in front of him (YES...before was sending it via email)but SO many other apps have this rubber-band grab the area of screen and sent it in chat programsI use QQ which once i discovered that feature it becomes a GREAT TRAINING tool...as you can explain thingsto people in text and IMAGE grabs....say of a software or in MY case, showing how to use Wordpressetc...So i hope you can, or if someone else reading can give you any directions, would be great.Appreciate ANY time with your help and thanks for looking into it.Im reasonable ok with NB, but sometimes i miss the obvious, like using the debugger to SEE whats going on.That tip helped me with another issue.Again, thanks for your help. Rob.

dec wrote:"Problem" is TCP/IP can't guarantee you send or receive the data in one time.

The plugin works fine if you send say 10-15 KB of text, but no more than this.

I am not sure I fully understand the issue but sending mime encoded files via TCP having limits could be solved by breaking up files into smaller blocks (mime encoded files are ascii text) and the first bit of information sent to the recipient is the number of blocks and the checksum/hash of each block. If the client receives a block and the checksums match, it tells the sender it has been received OK. Otherwise it gets notified it must be sent again. Once all the blocks are sent, then assemble the smaller blocks into the larger one.

dec wrote:"Problem" is TCP/IP can't guarantee you send or receive the data in one time.

The plugin works fine if you send say 10-15 KB of text, but no more than this.

I am not sure I fully understand the issue but sending mime encoded files via TCP having limits could be solved by breaking up files into smaller blocks (mime encoded files are ascii text) and the first bit of information sent to the recipient is the number of blocks and the checksum/hash of each block. If the client receives a block and the checksums match, it tells the sender it has been received OK. Otherwise it gets notified it must be sent again. Once all the blocks are sent, then assemble the smaller blocks into the larger one.

Something like you refer neccesary be made by the plugin itself and I can't found the way to do. I try various solutions with no success. The theory say yes, but the practice say no. The problem is I made npTalk after npMsgs. This last plugin have a limitation of 250 chars to be send, and I do not considerer this as a limitation by two reasons: firstly the limitation is imposed by the Windows API; secondly I found that even with this limitation the plugin can be useful.

When I develop npTalk I found some limitations too, althoug you can send more than 250 chars. However I do not thinking deeply in the TCP/IP protocol, but use the sockets in a more or less simple way, just like the samples I found on internet that never worries about large amount of data. So this is an absolutely mistake, because I can say npMsgs is limitated by the Windows API wich is involved, and this is true, but in fact npTalk are only limitated... because I don't know how to make the things in other way.

Of course I want to continue searching for a solution, but, to be honest, I test several possible solutions at this time and the things do not works like expected. So I am now really worry about this issue...

Thanks David. I use the originals Delphi "TServerSocket" and "TClientSocket", because I cannot handle with other solutions like Indy. However the refered components can do the job. The problem is not the protocol or the components, but probably the developer, so... I will continue searching for a solution...

I was wondering,can the string be broken up into smaller manageable sizes and 'streamed' to the other Pub?David, of course, this is not a fault of any plugin or anything at all..just trying to find a solutioneven if different part of neobook can do it. I appreciate all your trying to do,so thanks I thought Han's hpwBitmapToRtf/hpwRtfToBitmap or MimeEncode/Decode would work butyour saying its a limitation of the Tcpip sending 15k text, so as dpayer said, can i use a for each loop,breakup the encoded ASCII into variables and send a header saying an 'image' iscoming, like you did in example, then send those parts, as the receiver in the subroutine 'knows'to expect, say, 5 chunks stays in ITS loops until all assembled into one variable and then re-encodedand displayed?I did some screen grabs of small windows that i want to send and at MOST, those were 30-40Kbso reasonable small, and if the limit is only 15Kb then it would only take about 4-secs to send allparts,assemble and display....i thought, anyway.How to do as Dpayer said? Hmmm..my brain is jello at the moment haha If sending "image" i could send JPG to a folder on his website and have the remote pub, after receivea header text saying image coming to monitor that folder and when image arrives to download andreassemble..but again, just hoping for HOPE that there may be an easier way with such brilliant mindshere in the forum (crawl,crawl).I'll have a think about the "second option" today, I'd love to know how to DO this:" could be solved by breaking up files into smaller blocks ........ Once all the blocks are sent, then assemble the smaller blocks into the larger one.",Dpayerbut not sure how to do that at this stage, bit of reading to do.Thanks to all trying to help,appreciate it.Rob

Unfortuntally I think the publication cannot be care about this. In other words, in my opinion is the plugin which neccesary need to handle this question. I will continue today searching for the right solution. And this is only what I can say at this time... unfortunatelly.

Let me to say the progress about this issue today. Finally I found the way that allows to send large strings, however, I found another issue when this possible solution become. When I try the way that apparently work well in Delphi (I say sending an string more than 100 MB...) the same approach do not work very well in the plugin implementation. The code is the same, but the results are not, and in fact this is not the first time I found something like this while develop a plugin: the problem is this plugin is allready published, of course.

Even when I get ready to send (and receive) more than the currently available strings length from the plugin, we entry in problems when send say more than 500 KB of text. In fact we can send more than this, but the server (in this case I send the string from a client to a server) hang and I cannot found the way to prevent this. As I say above, the same code work more or less fine in my Delphi test application, sending dozens of MB do not hang the application, but when use the plugin they hang the server if we send this ammount of data.

I am really frustrating, because, even when I found useful the plugin in order to send small texts (and now this is possible in a more larger manner than is allow with the current version of the plugin) in fact I do not publish this plugin if found this issue before. As I say above, it's not the first time I neccesary abandond a plugin development because the same code do not work in the same way in both Delphi and the NeoBook plugin. This may occur because of my less knowledge, but at this point the important is this happend and not why happend.

I want to continue tomorrow in the research of a solution. I am ask to some Delphi developers if the way I choose to send the text is correct or can be take a better approach. Really I am feel like in a hole, because I repeat, even when the plugin can work better than the current version, I cannot be happy with a solution like that. Maybe I can limitate the ammount of text what the plugin can send, say to 200 KB, in order to prevent the server or client hang, and letting the user to decide if the plugin can be useful or not for their purposes.

Well. At this time and as I say above I want to continue for a possible solution to this.

I'm really interested in you can find a solution. As you know I have this plugin and would like to have that new capacity.I did not know you could send pictures in that way. Anyway, I do not think it's very difficult to cut the file into several parts and link them all when the recipient receives them.

CN_Iceman wrote:I'm really interested in you can find a solution. As you know I have this plugin and would like to have that new capacity.I did not know you could send pictures in that way. Anyway, I do not think it's very difficult to cut the file into several parts and link them all when the recipient receives them.

Good work David.

Greetings.

Thanks Jose. Well. In fact the plugin do not send files and do not have an action to do that. In principle are designed to act like npMsgs but for publications in different machines. npMsgs do not send files too, only text (and only 250 max.) but this do not make the plugin useless in my opinion. You cannot send a file, but can send the path or URL of a file, for example. Or just "commands" to ordering certain task. However, even when npTalk (right now, I continue working tomorrow) can now send more text than in the currently version, in fact I cannot be happy, and less happy when I found this limitation in plugin but not in the Delphi application I use for tests.

Really I don't know what to thing about. Right now I only can say that I want to continue working for the best solution for all.

Yes, the main function of the plugin is to send text, not files. I know that and that's how I'm using the plugin. In fact, I'm working on a program that works as a chat in my local network and at the same time plays some commands, such as shutting down a system remotely for example.

The fact is that I did not know you could convert an image into text form and then convert it back, and I found something very interesting in that.

Yes, the main function of the plugin is to send text, not files. I know that and that's how I'm using the plugin. In fact, I'm working on a program that works as a chat in my local network and at the same time plays some commands, such as shutting down a system remotely for example.

The fact is that I did not know you could convert an image into text form and then convert it back, and I found something very interesting in that.

As always, if you need any help ... you know.

Greetings.

Is possible to send images if you convert it to a base 64 text representation. But the problem remain. Here is (currently) a limitation of the ammount of text the server or client can receive without hang. This limitation do not affect if you plain to send only small pieces of text, even when you send text up to 200 KB, for example, but, more large text can hang the publication. I still continue researching for a solution, but remeber the solution I achieve work well in a Delphi application... the problem is now in the plugin and to be honest I can't say right now this can be solved.

Then probably I ask to the community (specially this plugin customers) if really want a plugin like this (with the limitation, which maybe finally are imposed by the plugin, truncate all the text larger than some size) or not, in order to take some decision about. What is my opinion? In some way I considerer the plugin useful, at the least I considerer the plugin useful even when the "original" limitation which of 5-8 KB of text! But even when the plugin right now can handle more text than this, certainly I cannot be really happy at all. I don't know what to do.

The idea of ​​the plugin is not sending large texts, I, in fact, do not use it for that. However, if you could send larger text could be seen as a plugin improvement.However, only with the effort you spend to help and improve, I already consider myself satisfied.

The idea of ​​the plugin is not sending large texts, I, in fact, do not use it for that. However, if you could send larger text could be seen as a plugin improvement.However, only with the effort you spend to help and improve, I already consider myself satisfied.