13 may 2002 Status report ----------------------------- As work with CVS proved not to be as easy as I had thought, I will use Igor' s channel to check the my files in and out. So, do not be surprised to find my updates checked in by user Igor.
I. I added an icon File Transfer service. Its bitmaps are ft.bmp and ft_sel.bmp. When open, the tabs appear: "Status", "Send a File..." and "Receive a file". At the time being, I am busy with implementing the "Send a File..." functionality. When user presses the "Send File" button, a dialog pops up reading "Choose File to Transfer for *UserName*" (as described in the Specification). File size is displayed in KB. Q: do I have to consider one KB contain 1024 bytes (as commonly adopted) or 1000 (somebody likes this best)? Personally I prefer 1024. The same question will relate MB when considering the "Receive a file" tab. II. "Status" tab. The Spec says it should monitor ALL the File Transfer activity within the lan. The FT processes that the current machine is invoked in have "Cancel" buttons. This approach has the following issues: - Broadcasts are required to notify all the lan of initiation and progress of all the FT process, which, I am afraid, might substantially affect both the lan traffic and Kaboodle efficiency. - FT monitoring gui will look rather cumbersome: as user opened "Status" tab they see something like: 1 <FROM USER A> <TO USER B> <FILE_1> <progress bar.......... > ... m <FROM ME> <TO USER C> <FILE_M> <progress bar..... > [CANCEL] n <FROM ME> <TO USER D> <FILE_N> <progress bar. > [CANCEL] Imagine. User wants to cancel transfer of his file <FILE_M>, he moves the mouse pointer above the Cancel button. At that, process 1 finishes. If Kaboodle performs a 1 line scroll, user may miss the proper button and click the wrong one. To avoid mistakes, Kaboodle should not perform such scrolls until closed. In that case, as Kaboodle monitors all lan FT activity, the number of lines will constantly grow and user will have to scroll through them. Bottom line: monitoring of the entire lan FT activity will substantially complicate both socket programming and user interface. My suggestion consists in the following. At the beginning stage, we implement monitoring of those files being transferred to and from the given machine only rather than the entire lan. III. When I was inserting the File Transfer service icon, I came across some redundant code. Thus, functions: CEFIcon *AddVPN(CGUID id, CString name); CEFIcon *AddVNC(CGUID id, CString name); only differ in two integer constants. I had to add my own function CEFIcon *AddFT(CGUID id, CString name); which, if follow the logic suggested, would make me copy the function body once again. I chose not to do so but retrofit the original function so to eliminate the redundant code and provide feasible icon updates in future. My new function is CEFIcon* AddServiceIcon(CGUID id, const CString& rStrName, UINT uiBmp, UINT uiBmpSel); and all the three above functions now delegate the calls to that one: CEFIcon *AddVPN(CGUID id, CString name); CEFIcon *AddVNC(CGUID id, CString name); CEFIcon *AddFT(CGUID id, CString name); The same issue was encountered in the classes: class CNIDVNCService : public CNIDService class CNIDVPNService : public CNIDService I moved the common functionality into the base class (which had already existed) and derived my own class class CNIDFTService : public CNIDService All the obsolete source code is left on in comments. IV. Enclosed is a sample gui written in MFC as stand-alone executable. -Oleg _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Kaboodle-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
