You can emit readyRead signal explicitly where you are using that class. mySerialPort msp; emit msp.readyRead(YourByteArray);
because signal is defined as public. But this may not be a good way for testing On Wed, Mar 29, 2017 at 4:32 PM, Murphy, Sean <smur...@walbro.com> wrote: > > I have to ask, why is it such a sin to have a stand alone program with a > > null modem cable and mini-tester as a testing tool. I have been working > > with serial ports off and on since the days of DOS 3.x and have always > > tested in this manner. The first piece of code one writes on a project > > which needs external inputs is the test tool to generate 1-N pre-defined > > inputs. There "should" be one laying around at the shop which was > > originally used to validate the product. > > There's nothing wrong with having a standalone program at all from a > technical standpoint. The question arose because of the bug showing up a > little more often recently, and a work deadline to release a version soon > - so > I was looking for a quick method to verify that my fix for the issue works. > I have a log of the data that produced the problem. I thought if I had a > way to playback that log without changing any of my serial port / parsing > code, that would be the quickest way to test the fix, without risking > generating > new bugs, by either having to modify my existing code, or having to write a > separate sender program. > > And I can guarantee there wasn't a tool laying around the shop, but as of > yesterday, there's now one in development! > Sean > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest