|
this XPdf viewer is very good and I plan to wrap it into my software installer for users to read my manual.
diligent hands rule....
modified 2hrs 15mins ago.
|
|
|
|
|
Good to hear. But any safe clicky link avaiable?
|
|
|
|
|
I embed that link to my message. thanks for the feedback![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
I browsed their license, if you use their Library files, that's different story.
but for PDF viewer there is no issue to distribute.
diligent hands rule....
|
|
|
|
|
Oh, sorry my eyes 
|
|
|
|
|
I would recommend you to post it to: Free Tools Discussion Boards[^]
It will last more than a couple of hours in the first page.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I know this board, but I can not easily find it from top menus...
diligent hands rule....
|
|
|
|
|
About 40 years ago I had a record (vinyl that time). I gave it away to a friend, but since about 30 years I'm looking for that.
The interpret was called approximatly 'bybatilax' or 'bibatylax' or ..., I can be easy wrong on spelling that. One song on that record -from which I was fascinated- was about thunderstorm with a great guitar part.
Any memories on something like that?
Thank you very much in advance
[Edit]
Neither google nor ChatGPT was successful
modified 5hrs ago.
|
|
|
|
|
|
Nope, but thank you anyway 
You are most probably to young 
modified 4hrs 10mins ago.
|
|
|
|
|
0x01AA wrote: You are most probably to young 
We had this conversation recently ... You said 40 years ago, so that puts me in my mid-teens... :P
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
That time (before 40 years) I counted as adult
|
|
|
|
|
You can't be that much older than me :P
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
1963
|
|
|
|
|
only by 5 years ... lol
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Can you remember how it went at all? If so, this might help: Song stuck in your head? Just hum to search[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
I'm kind of rubber ducking you all, so bear with me (or skip) and thanks.
It's the wee hours here. I don't know what I changed in my code, but one minute it was working.
The next minute every time I start it it's like the procedure that builds all the windows exits halfway through without creating everything, and then the app doesn't exit. (It appears to, but you have to kill it in TaskMan)
I should pack it in but that leaves me for want of something to do (I woke up recently), and code in a known bad state.
All of this mess is to simply read and write serial ports in win32, but due to a sort of polarity mismatch between the Arduino and Win32 APIs I need to spin a thread to continually fetch data from the COM port. This seems to be what is causing the problem. It's not a race condition though - it's consistent.
I need to do this due to the presence of a peek() function which peeks the next character in the stream, and an available() function which returns the # of bytes waiting in the receive buffer. Win32 has no such facilities, so I need to emulate them.
I'm wondering if I can't just cooperatively thread the whole thing. I already have my main application loop where I could poll each com port, but due to separation of the various parts of Winduino I need to expose an uncomfortable amount of serial functionality "publicly" to make that happen.
It kind of makes me want to give up and play fallout, but I really don't want to leave my code in its present state.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Ok, without knowing the details of your coding. Here are some very dumb assumptions and a question.
I assume that since you used taskman to kill the app that the CPU was not pegged and memory was not pegged. It sounds like a resource issue or a locking issue.
Did you try rebooting and running the app on a fresh machine with nothing else running?
|
|
|
|
|
Oh it's definitely a deadlock. I'm just not sure where, and I think a lot of it has to do with me misunderstanding the behavior when reading COM ports under win32.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Time to start adding some debugging output to narrow done where....
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
It's hanging on Opening the com port with FileOpenW(L"\\\\.\\COM25"...) despite it being valid. I may need to reboot as prior crashes could have hung the COM port or something. Still, I wish it would time out.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
|
honey the codewitch wrote: I need to spin a thread to continually fetch data from the COM port
Your thread can wait on an event flag using SetCommMask (hComm, EV_RXCHAR);. It's not that straightforward because sometimes, on some COM ports, Windows fails to trigger the event, so your thread has to wait with a timeout and recheck if any character has arrived.
You can see a piece of code here. It is probably more complicated than what you need because it supports multiple clients reading from the same port and also time-tags each incoming character. Code has been in use for eons and it's bulletproof. If you want a stripped down version let me know.
Mircea
|
|
|
|
|
Oooh I'll take a look.
Right now I'm getting a hang on open, which is unfortunate. I may need to reboot and start fresh, but I'll download what you linked to first. Thank you.
There's obviously some black magic here, and COM ports have never been particularly friendly when they decide not to work.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Okay, so now that I've looked at the code, I do have a question. I'm going to have to port the thread and crit sec code away from your mlib stuff, which is fine, but I was wondering why you use a crit sec when it seems to me a mutex might be more appropriate? (I haven't followed all of the code, I'm kind of basing this on my own attempts, plus it has been drilled into me to avoid crit secs)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
