- Welcome to The MASM Forum.
News:
Masm32 SDK description, downloads and other helpful links
Message to All Guests
Recent posts
#11
Windows API / Re: Adventures in programming:...
Last post by NoCforMe - Today at 02:36:26 PMNo message loop in my code, I'm using a dialog as the main window, so the dialog manager is running the message loop. (Could that be part of the problem?)
The thread finishes when GetAllDirsAndFiles() finishes the disk scan.
I'm trying to avoid getting into the details of the source at this point; would like to deal with this on a conceptual level.
I will give you the complete routine that's running as a separate thread:
The thread finishes when GetAllDirsAndFiles() finishes the disk scan.
I'm trying to avoid getting into the details of the source at this point; would like to deal with this on a conceptual level.
I will give you the complete routine that's running as a separate thread:
Code Select
FillFileList PROC
INVOKE GetAllDirsAndFiles, 0 ;Start @ file entry[0] ("root").
INVOKE SendMessage, DialogHandle, $MSG_FillTreeview, 0, 0
INVOKE ExitThread, 0
RET
FillFileList ENDP
BTW, is that RET even ever reached? can I remove it? #12
The Orphanage / Re: I need a program called "F...
Last post by learn64bit - Today at 02:28:44 PMI think that you misunderstand ascii text.
this app not process just ascii text.
"You call it the start of the line in your code"
no, I call it line separator. you can modify 0Dh,0Ah(2bytes) to 000000h(3bytes) or anything you want.
The start of the line is after CRLF except for the first line.
in this app, line is pure line, no start somgthing, no ending sometiing or terminator.
it is not ascii text, nor a .txt file.
right, you can mofidy .txt to .bin, .dat, .dump or .database anthing you want.
this app not process just ascii text.
"You call it the start of the line in your code"
no, I call it line separator. you can modify 0Dh,0Ah(2bytes) to 000000h(3bytes) or anything you want.
The start of the line is after CRLF except for the first line.
in this app, line is pure line, no start somgthing, no ending sometiing or terminator.
it is not ascii text, nor a .txt file.
right, you can mofidy .txt to .bin, .dat, .dump or .database anthing you want.
#13
Windows API / Re: Adventures in programming:...
Last post by sinsi - Today at 02:22:50 PMDoes your message pump use GetMessage or PeekMessage?
How do you know when the thread is finished?
Source code, source code, source code
How do you know when the thread is finished?
Source code, source code, source code
#14
The Orphanage / Re: I need a program called "F...
Last post by sudoku - Today at 02:18:04 PMI took a look at your program. It does 'something'. Congratulations.
I think that you misunderstand ascii text.
Hex byte 00h does not equal ascii zero "0", which is 30h. That it why you will not see it in a text editor like notepad.exe.
Also the carriage return/line feed (CRLF) is the line terminator, meaning the end of the line - not the beginning of the line - although there may be another line after CRLF. You call it the start of the line in your code, that is incorrect. The start of the line is after CRLF except for the first line which may or may not have a preceding CRLF (an empty line)
If there is a hex zero in an ascii string, that is considered as the string terminator or end of the string.
You keep calling a.txt and b.txt text files. If either of them contain a hex zero byte 00h, then it is not ascii text, nor a .txt file.
I did some testing with your program, using real ascii text for a.txt and b.txt. It seems to work. Opening c.txt and d.txt in notepad, the results are displayed without using a hex editor.
I think that you are confused between hex zero 00 and ascii "0"(30h) or any other ascii numbers - I think that is where some of your confusion is stemming from.
30h = ascii "0"
31h = ascii "1"
32h = ascii "2"
and so on...
I think that you misunderstand ascii text.
Hex byte 00h does not equal ascii zero "0", which is 30h. That it why you will not see it in a text editor like notepad.exe.
Also the carriage return/line feed (CRLF) is the line terminator, meaning the end of the line - not the beginning of the line - although there may be another line after CRLF. You call it the start of the line in your code, that is incorrect. The start of the line is after CRLF except for the first line which may or may not have a preceding CRLF (an empty line)
If there is a hex zero in an ascii string, that is considered as the string terminator or end of the string.
You keep calling a.txt and b.txt text files. If either of them contain a hex zero byte 00h, then it is not ascii text, nor a .txt file.
I did some testing with your program, using real ascii text for a.txt and b.txt. It seems to work. Opening c.txt and d.txt in notepad, the results are displayed without using a hex editor.
I think that you are confused between hex zero 00 and ascii "0"(30h) or any other ascii numbers - I think that is where some of your confusion is stemming from.
30h = ascii "0"
31h = ascii "1"
32h = ascii "2"
and so on...
#15
Windows API / Re: Adventures in programming:...
Last post by NoCforMe - Today at 02:04:19 PMNew version (.exe only) attached here. Everything is implemented that I think I want except for image zooming (coming real soon now ...). And I fixed some problems that were causing extreme flakiness and crashing.
The flakiness apparently had a very simple cause. A while back sinsi advised me that I needed to close the find handle that was returned by FindFirstFile(). Well, I did that, and it solved some problems at the time. However, stupid me; I was just calling CloseFindHandle() without checking whether the handle I was trying to close was valid or not! Now I guess I have to plead guilty to being kind of careless here; a lot of Win32 CloseXXX() functions are very forgiving if you pass them a bogus handle; they just ignore it. Not CloseFindHandle()! It stands for no nonsense. Anyhow, after fixing this, no more crashes or odd behavior (like the app closing when I click on the "Choose Folder" button).
There are two remaining problems, though, neither one a show-stopper, but annoying:
1. The progress bar: For long disk scans, I put up a "Waiting:" prompt and a progress bar that's supposed to move continuously in "marquee" mode. Except that it doesn't. It just sits there.
This all has to do with my use of a separate thread for the disk-scanning code. At this point I'm not sure at all I'm doing the right thing here. Let me explain what's going on in my code.
In pseudocode:
Can anyone tell me from looking at this scheme whether I'm doing the right thing here so far as threading goes? The idea is to isolate the code which has to grind away at the disk scan so that the user interface doesn't go unresponsive, which is working. But if the UI is responsive, why isn't that damn progress bar moving?
2. Resizing blues: I came up with some pretty fancy resizing code; try it out. It keeps the widths of the treeview and pic-display windows proportional while maintaining the spacing between controls and the edge of the dialog; that part works great.
What's not so great is the intense flicker that results from resizing, especially if a good-sized image is being displayed. (It's not as bad with a small image or no image.) Any suggestions? Keep in mind that I'm moving or resizing 3 windows in addition to the dialog window (plus the status bar).
The flakiness apparently had a very simple cause. A while back sinsi advised me that I needed to close the find handle that was returned by FindFirstFile(). Well, I did that, and it solved some problems at the time. However, stupid me; I was just calling CloseFindHandle() without checking whether the handle I was trying to close was valid or not! Now I guess I have to plead guilty to being kind of careless here; a lot of Win32 CloseXXX() functions are very forgiving if you pass them a bogus handle; they just ignore it. Not CloseFindHandle()! It stands for no nonsense. Anyhow, after fixing this, no more crashes or odd behavior (like the app closing when I click on the "Choose Folder" button).
There are two remaining problems, though, neither one a show-stopper, but annoying:
1. The progress bar: For long disk scans, I put up a "Waiting:" prompt and a progress bar that's supposed to move continuously in "marquee" mode. Except that it doesn't. It just sits there.
This all has to do with my use of a separate thread for the disk-scanning code. At this point I'm not sure at all I'm doing the right thing here. Let me explain what's going on in my code.
In pseudocode:
Code Select
start a new scan:
BusyFindingFlag = TRUE ;locks out controls while scan is in progress
create "root" item in treeview
PutUpProgressBar():
show "Waiting:" (static text)
show progress bar
set progress bar in marquee mode (PBM_SETMARQUEE)
CreateThread() for FillFileList():
(everything at this level is in the new thread)
FindAllDirsAndFiles() ;this is the recursive routine that takes a lot of time
Send $MSG_FillTreeview to the dialog
which calls FillTreeview() to populate the treeview
ExitThread()
Hopefully that makes sense. It works find so far as the application goes, but the progress bar control never moves. From reading a lot of stuff online about this (none of it on Micro$oft Learn, however!), it seems that what's happening is that the main thread of the program isn't getting enough cycles to service the progress bar. (My next move is to monitor the messages going to that control.)Can anyone tell me from looking at this scheme whether I'm doing the right thing here so far as threading goes? The idea is to isolate the code which has to grind away at the disk scan so that the user interface doesn't go unresponsive, which is working. But if the UI is responsive, why isn't that damn progress bar moving?
2. Resizing blues: I came up with some pretty fancy resizing code; try it out. It keeps the widths of the treeview and pic-display windows proportional while maintaining the spacing between controls and the edge of the dialog; that part works great.
What's not so great is the intense flicker that results from resizing, especially if a good-sized image is being displayed. (It's not as bad with a small image or no image.) Any suggestions? Keep in mind that I'm moving or resizing 3 windows in addition to the dialog window (plus the status bar).
#16
The Orphanage / Re: I need a program called "F...
Last post by learn64bit - Today at 01:21:01 PManother test passed
(a lot people have difficuty understand ml&link asm code or Windows API. so I add a lot of print text)
v250: a.txt, b.txt, findLine.asm and findLine.cmd
(a lot people have difficuty understand ml&link asm code or Windows API. so I add a lot of print text)
v250: a.txt, b.txt, findLine.asm and findLine.cmd
#17
The Laboratory / Re: Very fast hex$ (our hobby ...
Last post by sudoku - Today at 12:37:03 PMQuote from: sinsi on Today at 12:29:32 PMIt's a silly idea as far as using it for something so trivial...Right. That's why you would do as many conversion as possible to justify the overhead... not just one conversion. The overhead might negate any savings otherwise. Would be perfect for a spreadsheet, methinks.
#18
The Laboratory / Re: Very fast hex$ (our hobby ...
Last post by sudoku - Today at 12:31:28 PM@sinsi: You're crazy. 
I "might" take a look at this later... "maybe" (I'm lazy)
I "might" take a look at this later... "maybe" (I'm lazy)
#19
The Laboratory / Re: Very fast hex$ (our hobby ...
Last post by sinsi - Today at 12:29:32 PMYou could create the threads and leave them suspended, just wake them up to use them then back to sleep.
It's a silly idea as far as using it for something so trivial, but there aren't that many practical uses for threads.
Quote from: sudoku on Today at 12:19:41 PMAre you already experimenting with it?I'm waiting for someone to tell me "you're crazy" or "hmmm, interesting".
It's a silly idea as far as using it for something so trivial, but there aren't that many practical uses for threads.
#20
The Laboratory / Re: Very fast hex$ (our hobby ...
Last post by sudoku - Today at 12:19:41 PMQuote from: sinsi on Today at 12:02:37 PM...multithreaded hex$You would have to include the overhead for the thread creation, etc. in the times... to be fair to the other algos == not from thread(s) start to thread(s) end only. Are you already experimenting with it?
... Yes, *should* be faster.