Re: display array in a frame wnd
- From: "J-F Portala" <jfportala@xxxxxxx>
- Date: Thu, 6 Sep 2007 22:59:13 +0200
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> a écrit dans le message de
news: 8i00e3lib409379cbl4tlgov0n3v6rr69t@xxxxxxxxxx
See below,,,I think it depends on the application. I really used for several years
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.
document/view architecture, but
it was a constraint for me to think C++ objects in this architecture.
****I only work in C++ objects. When I need graphical view, I have created a
****
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.
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.
****Perhaps your application with several identical mass spectroscopes is
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).
****
adapted to such an architecture, but in my case, I have some doubts.
CFrameWnd seems to me interesting way, it is easy to add menus, status bar(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.
(the sole thing I need to do is displaying my images...)
Esay to create, to hide...and independant.
****I think this is due to portability. This library works under linux and can
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.
****
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/
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
.
- Follow-Ups:
- Re: display array in a frame wnd
- From: Joseph M . Newcomer
- Re: display array in a frame wnd
- References:
- display array in a frame wnd
- From: J-F Portala
- Re: display array in a frame wnd
- From: Joseph M . Newcomer
- Re: display array in a frame wnd
- From: J-F Portala
- Re: display array in a frame wnd
- From: Joseph M . Newcomer
- Re: display array in a frame wnd
- From: J-F Portala
- Re: display array in a frame wnd
- From: Joseph M . Newcomer
- Re: display array in a frame wnd
- From: J-F Portala
- Re: display array in a frame wnd
- From: Joseph M . Newcomer
- display array in a frame wnd
- Prev by Date: Re: WinDiff done right?
- Next by Date: MFC Copy progress
- Previous by thread: Re: display array in a frame wnd
- Next by thread: Re: display array in a frame wnd
- Index(es):
Relevant Pages
|