Re: display array in a frame wnd

On Thu, 6 Sep 2007 22:59:13 +0200, "J-F Portala" <jfportala@xxxxxxx> wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> a écrit dans le message de
news: 8i00e3lib409379cbl4tlgov0n3v6rr69t@xxxxxxxxxx
See below,,,
On Thu, 6 Sep 2007 11:45:05 +0200, "J-F Portala" <jfportala@xxxxxxx>
wrote:

Hi Joseph,
I have read some articles on document/view architecture (I began with this
architecture 10 years ago), but
rapidly I found it not adapted to my needs, and too heavy and complicated
for my needs.
*****
I find that judgments like this are rarely valid. I once had a client who
was trying
desperately to remove the CDocument class from their app because "it's too
complicated".
The only thing that was complicated was a failure to understand how to use
it. It is
*not* "too complicated" and works very easily and naturally.
I think it depends on the application. I really used for several years
document/view architecture, but
it was a constraint for me to think C++ objects in this architecture.
****
MFC creates some paradigms. You can use them or fight them, or ignore them. I've found
it easier to use them. Fighting them is always losing, and ignoring them generates
unnecessary work.
****
****

I am working in the field of industry, where my applications have to give
results.(i don't have many interactions with user)
For example, in my last application,
I have two cameras which are displayed in two frames in real time, (there
is
a special menu in these windows (zoom+ and zoom-) abd a status bar where
location of the mouse
is displayed).
****
So, the input data from the camera is the document. In the case I just
mentioned, they
made the same excuses, "We don't have files to write, we just have these
embedded
controllers at the end of a wire". Yep. And the controllers are the
document, and the
CDocument class is the proxy to that document. Amazing how many kludged
misfeatures went
away once they did that! And they could add new views, such as a
graphical view of the
data, because it was now trivial to do so. You're probably thinking about
the problem as
a traditional C program; this is MFC in C++, and the paradigms these
libraries present
should be taken advantage of.
I only work in C++ objects. When I need graphical view, I have created a
subclass of CframeWnd (sorry, I insist)
that I can create on the fly to display some data.
It takes me on line to create and display datas.
I agree that for printing datas, MDI architecture is usefull.
****
Printing is usually one of the least interesting aspects of MDI. Document/view is the
most important, and this is based on the fact that I *rarely* have any reason to do
printing from a view!

If you insist on creating your own CFrameWnd-derived class, feel free, but I don't
understand the need to generate so much extra effort. The problem is that you see one
short-term line, but then when you hit a problem for which doc/view is the natural
paradigm, you're stuck, and insisting on doing things in a fairly unnatural (for MFC) way
then means you need to create all kinds of workarounds. Selecting a poorly-designed
library doesn't help the problem, either. A well-designed library uses YOUR windows, and
doesn't create its own, or if it does create its own, it lets you specify the parent,
size, control ID, etc. If it does drawing, it wouldn't even consider creating a window,
but instead, accepts a DC to an arbitrary window.
****

****
Simultaneously, I can display another window with a special menu dedicated
to calibration of my cameras, and I have also the main window with the
main
menu
****
Yep, that's another view! Sounds like doc/view to me! One view shows
data from the
document, another view lets you manipulate the parameters of the
document...I've got a
system like this that handles multiple mass spectroscopes, couldn't have
done it if I
hadn't had doc/view architecture (the document is the mass spectroscope).
****
Perhaps your application with several identical mass spectroscopes is
adapted to such an architecture, but in my case, I have some doubts.
****
You said you have several cameras (documetns) and need to have a control setup view and a
data view. Wow. That sounds like doc/view to me! I think you have decided it doesn't
match by not thinking about what the paradigms are, but instead thinking about what the
code looks like.
****

(the view of this window is reduced to only menu bar because I have
nothing
to do with )
All these different windows are subclasses of CFrameWnd.
****
Seems a circuitous way to achieve a simple goal.
CFrameWnd seems to me interesting way, it is easy to add menus, status bar
(the sole thing I need to do is displaying my images...)
Esay to create, to hide...and independant.
*****
So is a CView. And a CDocument. And once you've done it, you have the code, so even if
it is six lines, it is always the same six lines...
****

****
It works quite well, but in the library (Matrox) I use, the image is
attached to the HWND handle of the CFrameWnd. (I don't know how it is
done)
I can't use this library anymore (proprietary) and I am working now with
OPENCV (the most powerfull opensource library in image processing).
This library had some functions to display images (cvNamedWindow...) but
there are some features I need (menu and status bar) that I can't add.
****
Well, it isn't very powerful if it can't do something simple like allow
you to give it the
window into which it is to generate its display. A library that thinks it
owns the right
to create the window is suffering from poor design. An imaging library
should be able to
draw into any window you give it. Most libraries I use just require a DC;
they don't even
try to create that. Good library design works *with* the user; bad
library design works
*against* the user. A library that requires that it create the window,
but doesn't let
you specity the parent or the size, is a bad design.
****
I think this is due to portability. This library works under linux and can
use gtk or other tools.
The part concerning display is an addition to the image processing library.
This addition permits to display easily images and capture frames from
sevelral interfaces (ieee, ...)
You can have a brief presentation here.
http://opencvlibrary.sourceforge.net/

****
So in linux, in strikes me that there is even less reason to have it create windows; the
natural paradigm would be to take a GC to a window, or to create a child window of a known
parent and size. At least that's the sort of thing I did back when I programmed Unix.
Portability is not impacted by whether or not it creates windows! Since window creation
is nonportable, and graphical drawing is nonportable, I'm not sure how all of this can be
made less portable by letting the user specify the window or graphical drawing context
(GCs in X-windows, DCs in Windows...)
joe
****
See my essays on bitmaps on my MVP Tips site.
Very good job.
I have found BitMapInfo that I try to understand.
Certain tips are very interesting

Thank you for the time you spend with me.

Jeff

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: display array in a frame wnd
    ... I have read some articles on document/view architecture (I began with this ... It takes me on line to create and display datas. ... window into which it is to generate its display. ... Most libraries I use just require a DC; ...
    (microsoft.public.vc.mfc)
  • Re: display array in a frame wnd
    ... I have read some articles on document/view architecture (I began with this ... window into which it is to generate its display. ... Most libraries I use just require a DC; ...
    (microsoft.public.vc.mfc)
  • Re: Update query to clean "N/A"s in exporteddata
    ... press F2 in a code window to View the Object Browser ... change the library to "VBA" (for instance, instead of <all libraries>) and look at the classes of functions -- click on a class and then click on a function in the right pane. ... this is a great library to look up help with in the Object Browser as the later DAO libraries don't always have help on everything. ...
    (microsoft.public.access.queries)
  • Re: Shared libraries and modules
    ... another computer architecture which should have been built ... modules and libraries that pervades the computer world today. ... not want to have the code, say, for a "stack of widgets" being different ... If a program in a class-based language wished to ...
    (comp.sys.acorn.misc)
  • Re: linking to libraries on A series
    ... Some languages cannot directly talk to system libraries ... DCILibrary interface are you referring to -- the ANSI COBOL-74 standard one that is related to the COMMUNICATIONS SECTION, or the one that is supported by Transaction Server (COMS)? ... An Agenda in COMS defines how a message will be handled once its routing is determined. ... If a Trancode is not recognized in the message (or none have been defined in COMS Utility for the Window), a Window can -- and usually does -- have a default input Agenda to which the message will be routed. ...
    (comp.sys.unisys)