I got a problem im not 100% on the best course of action, so i thought i would share it for advice.

Im 99% finished a file tool that works on two directories at once. It works via a loop going thru all 'checked' items in a listview. My problem is i want to present a report at the end of the opperation in a MODAL dialog box.

I thought at first i would make a global memory buffer of say 4Kb and *assume* the report wont get bigger than this. (I can not promise it wont). The better idea would be to update the edit control in the loop, appending more to it each time. However, i want it to be modal, so i cant create, hide, fill, and then show the dialog at the end.

I thought of swapping to file a 'log' file, and then presenting the log file in the edit box... but not sure if there is better approaches.

If you have suggestions, lemme know.
Posted on 2003-08-17 14:01:01 by NaN
Why not make the edit a child of the dialog that is displayed or a hidden non-modal dialog and then when it comes time to show the modal dialog use SetParent to swap it into the dialog ? This meets all of the requirements., it does present the slight problem that after the swap the edit's messages will still be sent to it's original parent but that is minor.
Posted on 2003-08-17 15:01:40 by donkey
Thats a neat trick.. I've never tried it... to be honest, I simply didnt think something like that is possible...

But after you suggest it, i cant see any direct violations in doing so. As you said, you have to reroute messages to the dialog box, since its already registered to a different window, but thats about it that i can see too...

I will give it a try... It will definitely save me the headache of managing a chunk of memory, and let the control do so instead ;)

Thanks alot Donkey!
Posted on 2003-08-17 15:36:55 by NaN
You're welcome NaN,

I've never tried it with edit controls but if you check my TBPaint package, almost all of the child controls of the dialogs are actually created on the main dialog and shifted. This sends their notification messages to the main window, let's me have one main loop and just use basic sustenance for the other dialogs.

PS: I'm looking for bug testers for the toolbar paint package if you're interested

Posted on 2003-08-17 16:15:04 by donkey
Sure i will check it out when im finished with this.. (99.99% done ;) )

I have one question..

I didnt write any 'reroute' code cause I figured it wasnt needed. I have flags set to lock out editng so all a user can really do is read it. For this reason, i figured i can ignore any parent notice messages. This idea is working in practice, but im getting hung up on a minor detail thats starting to bug me.

After i append all the text to the edit control, pass it to the modal dialgo box as a param, and show it by converting the parent control in the dialog box's init callback, it will show everything has programmed! However, it also shows all edit text as selected???

For the life of me, i cant convince it to "deselect" before showing. Everytime i get the report everthing is all Blue-highlighted.

I have tried "invoke SendMessage, hEdit, EM_SETSEL, 0,0" at many places, both befor i switch the parents, and after. Neither show any difference in the end. For this reason, im assuming it must be something that happens after the InitDialog message is processed. Which more or less comes back to the rerouting of messages (which i decided not to do).

The other reason is because i dont think i have done this trick in any other form before. What messages am i looking for to reroute to the dialog box?? The origional parent is also a dialog box. I've always assumed that the hWnd parameter for any dialog would ONLY be its own handle. Are you suggesting to trap for hEdit handles (child handle) to be passed in through the dialog proc as well??

Maybe im being bone headed over this (gut feeling is i am), but if you can shed a bit of light on just what to look for when rerouting it would be appreciated ;)

PS: I also tried EM_SETSEL with -1, 0 and still not change :rolleyes:

Thanks again Donkey
Posted on 2003-08-17 17:47:39 by NaN
Dah.. wasting way too much time on something trivial.. (sounds like an M$ Edit control to me :rolleyes: )

I've tried *everything* but throwing physical objects at the screen :tongue: . I've definitely trapped and confirmed this 'behavior' to where I pass the Edit window into another dialog's posession. I've confirmed that there is no "select all" highlighting if i DONT pass it in, but it always "select all" highlights the text if I do pass parental ownership to another dialog.

Absolutely bizzarre behavior, cause nothing i can do will convince it to let go, unless i physically click in the window space. (Yes, i've tried SetFocus stuff, and a handfull of other tricks simulating clicks, simulating keyboard hits, etc. etc. etc.)

Posted on 2003-08-17 19:12:13 by NaN
Bizarre problem, it only seems to happen if you change the parent in the WM_INITDIALOG message. BTW it will also do this with any text inan edit control regardless of whether you have set the parent or not. Just try initializing the text in an edit control in your WM_INITDIALOG message, it will be selected when the edit is displayed. I'll try to find another message that will work for the transfer...

If you use the followingin your second dialog proc:
.elseif uMsg == WM_SHOWWINDOW

invoke GetParent,hEdit
.IF eax != hWin
invoke SetParent,hEdit,hWin
The text is not selected, it is only when the WM_INITDIALOG is used to set it. This selection thing occurs on all edit controls that have their text written in a WM_INITDIALOG message handler. So, if you can think of another message to handle it in that's your solution. I could not find any messages that were relayed to the old parent.
Posted on 2003-08-17 20:20:02 by donkey
Ya, thanks for replying. I was afraid this would be the only answer. ( Soo slopy ;) )

Anywho, I did just this with a Timer and hid the window until the timer gave the window a couple of hits to deselect everything. Once the time runs out, it shows the window. It does this in 20ms (in Theory), but you can still see a delay if your looking for it ;) . I can live with it anyways...

Thanks you for you help and thoughts over the last couple of days... Here is the final product. Its mainly for work, but if you can find other uses feel free to do what ever you want (open to all).

The tool is designed to compare two separate directories for thier file contents. Much like Docking station software, it is to update each directory with missing files between them, or if a file is more recient than the other.

At work, we are responsible to keep a backup of the projects we work on which resides on a separate network drive. This tool is ideal for such applications cause more often than not, some files are modified directly from the network, and other times its not. This takes the guess work out of it (to some extent ;) ).

I put appropriate warning dialogs in place, but be warned, it has potential to overwrite older files you were 'hanging on to'... However, i left the safeguards in for READONLY file types.

This is My First real RadASM project :alright:
There is lots of goodies in there for people to learn from:

    [*]A pinch of COM for Directory Paths
    [*]A touch of OOP with LinkedLists
    [*]File/Directory accessing and copying
    [*]File Time evaluation and conversion to Local time
    [*]Listview Control usage with checkboxes
    [*]Colored Edit boxes with WM_CTLCOLOREDIT
    [*]Custom "Error" boxes
    [*]Using the SetTimer/KillTimer with a callback
    [*]Setting and using a combox box
    [*]Some mild memory (heap) and control management (as this post started off with ;) )
    This is all i can think of off hand. Im sure there is more.

    I've tested the snot outa it, but there bound to be an OS/version related bug somewhere. Let me know if you find one ;)


    :EDIT: See link below....
Posted on 2003-08-17 21:56:17 by NaN
:( ; Fill the Filter combo box with choices :(
Posted on 2003-08-18 00:40:42 by S.T.A.S.
Dah... got a new problem...

I took it to work today and (no surprises) it either crashes or dont copy anything (or even execute the copy loop) on my work computer...

Win2000 with Novel Network Login et. al.

It also did simular on an XP machine with the same.

So as far as i can tell (without debuggin on these machines), it must have some access privilages that im violating and not catching as an error (on some API). Doesnt help much i realize... But it does get the directory list, and it does filter as designed to... its only when the DoCopy function executes that it gets a little wierd...

Maybe the NT/2000/XP os's dont like the way im off loading a control to a new parent??

I would have figured it was the CopyFile API, but ironically, its not even getting this far... so im stumped at this point without finding a moment to debug on the 2000 machine at work.

If anyone know of "common knowledge" issues regarding file access on NT/2000/XP machines that i might be over looking please let me know... anything helps, cause im more or less ignorant of the quirks that differenciates Win9x and NT based OS's....

Thanks again!
Posted on 2003-08-18 12:14:11 by NaN
Well I got a moment after work to debug it on the machines at work (love RadASM for its portability).

I discovered that there was 2 bugs in it that Win9x doesnt seem to mind:

1) The Findfiles operation with the FindFirstFile and FindNextFile api's have a different "view" of file directories. In Win9x there is always the "." and ".." as the first two "files" returned. I had manually skipped over them so not to include it. On NT/2000/XP boxes it seems that there is only one of them (either "." or ".." but not both). I was quite surprised by this. Anywho, on NT/XP/2000 machines this would crash because of it. I removed the skip one ahead call to FindNext before the loop, and all was well here... (Still need to go home and check out how this affects Win9x without it). If i start getting ".." in the listings, i will have do directly check for these and ignore them, rather than count on them being the first two entries in every directory.

2) The windows message: LVM_GETITEM will not retrieve the item state, even with the imask haveing LVIS_STATE. On win9x it returns in the structure as it should, but in NT/XP/2000 machines, it returns 0. This is bizzare as well. I check the structure for the LVITEM and it was aligned on DWORD boundries, do this is not the bug. My only guess is its expects a different structure than the LVITEM ??

Anywho, the fix is calling separately for LVM_GETITEMSTATE for the state, and then LVM_GETITEM after for the param info (i was previously doing both in one call via. masks). Like i said, works on Win9x, and not on the "all mighty NT" os' :rolleyes:

Anyways, i will post a final revision later on tonight for those who want it...
Posted on 2003-08-18 17:23:04 by NaN
Hi NaN,

I usually just check the first byte of the file name...

lea eax,FileName
mov al,
.IF al == "."
;skip it

Since the first character cannot be a "." it has to be either "." or ".."
Posted on 2003-08-18 17:28:41 by donkey
Thanks for the Tip Donkey, I followed your advice here ;)

Anyways, this should be a final revision with NT/XP/2000 support as well.... not much changed...

Posted on 2003-08-18 21:46:05 by NaN

Since the first character cannot be a "." it has to be either "." or ".."

Actually, it can be.
Not from Explorer, but from CMD or even NotePad.
You should use a full string comparison if the first char is a ".".
Posted on 2003-08-18 22:15:41 by GogetaSSJ4