dev-cpp-users — Dev-C++ users discussion list

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Michael C U. <mu...@cb...>]

One other drawback to idle functions is that they cannot take advantage of
a second CPU like a thread can.

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Michael C U. <mu...@cb...>]

On Fri, 16 Jan 2004, Daniel K. O. wrote:

> The idle funcs have low priority by default, your thread could call
> gtk_idle_add a million times, and if the GUI is still busy with other
> things, the idle funcs will wait.

True. This works. But its pretty old fashioned and not nearly as
responsive as doing the update in a seperate thread. Generally, this is
how we used to do things before Windows had preemptive multitasking.  But
now that we have preemptive multitasking, we don't like to use idle
methods anymore.

As an example, in Petzold's book, Programming Microsoft Windows (the Bible
on the Windows API), there is a program that draws random rectangles on
the screen as fast as the computer can draw them. The example uses the
PeekMessage function to only draw when the application is otherwise idle.
However, if you move the mouse cursor through the random rectangle frame,
it is noticably sluggish as the random rectangle loop runs between the
firing of mouse events.

Later in the book, the same program appears again, but this time using a
seperate thread to draw the rectangles. If you try both examples, I think
you find that the threaded version is more responsive than the version
that uses PeekMessage().



Then they all will run; or you can
> just change their priority, calling gtk_idle_add_full, giving them more
> priority, for example, depeinding what you want. I don't think you can
> freely define this behavior in a log of GUI toolkits.
>
>
> >Animation and VR simulations that require rapid repainting of the display
> >are another area where you often don't want to tie up the main thread by
> >forcing it to handle the paint requests and such. The application can
> >become extremely unresponsive if the main thread has to handle such paint
> >intensive tasks.
> >
>
> Yeah, this really seems a problem.
> But GTK+ isn't intended for intensive repainting, like VR and
> Animations. You can use something like GtkGLExt, or GtkSDL, or something
> else, and plug this extra widget into your application. To manipulate
> their content you won't need to use Gtk+ API calls, you'll use
> SDL_BlitSurface, glVertex, etc. They should work fine when running from
> another thread.
>
>
>
> Daniel K. O.
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Daniel K. O. <dan...@ya...>]

Michael C Urban wrote:

>Updating the GUI in the main thread can cause noticable delays in the user
>interface. The progress bar is a good example. If you update that from the
>main thread, then every time the main thread has to repaint the progress
>dialog, it's going to interrupt the user experience.
>  
>


I don't think repainting the progress bar could take more time than 
painting a label... the idea isn't to make all the job in the main 
thread, just use a function that receives one arg, and call something like:

---
gboolean my_idle_callback_that_updates_the_progress_bar()
{
    gdk_threads_enter(); /* idle funcs run outside the lock */

    /* my_val is set in the other thread, inside 
gdk_threads_enter()/leave(),
    so the gui is not updated ouside the main thread, no problem at all.
     Now the idle func just have to retrieve the value, and use it properly.
 */
    float pb =  (float)g_object_get_data(G_OBJECT(my_progress_bar), 
"my_val");  
   
    gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(my_progress_bar), pb);

    if (pb>0.99) { /* are we finished? lets make the GUI sensitive again */
       gtk_widget_set_sensitive(toplevel_window, TRUE);

       /* here we could also change some texts, show a message window, 
play some sound, etc */
    }
  
    gdk_threads_leave();
    return FALSE; /* run this idle func just once */
}
---


The idle funcs have low priority by default, your thread could call 
gtk_idle_add a million times, and if the GUI is still busy with other 
things, the idle funcs will wait. Then they all will run; or you can 
just change their priority, calling gtk_idle_add_full, giving them more 
priority, for example, depeinding what you want. I don't think you can 
freely define this behavior in a log of GUI toolkits.


>Animation and VR simulations that require rapid repainting of the display
>are another area where you often don't want to tie up the main thread by
>forcing it to handle the paint requests and such. The application can
>become extremely unresponsive if the main thread has to handle such paint
>intensive tasks.
>

Yeah, this really seems a problem.
But GTK+ isn't intended for intensive repainting, like VR and 
Animations. You can use something like GtkGLExt, or GtkSDL, or something 
else, and plug this extra widget into your application. To manipulate 
their content you won't need to use Gtk+ API calls, you'll use 
SDL_BlitSurface, glVertex, etc. They should work fine when running from 
another thread.



Daniel K. O.

RE: [Dev-C++] dll inspection tools?

[Damien A <g_...@ho...>]

<html><div style='background-color:'><DIV class=RTE>
<P><BR>This is found on the&nbsp; WinXP Pro CD or installed with VC6 as a "depends.exe" or go here:</P>
<P><A href="http://www.dependencywalker.com">http://www.dependencywalker.com</A><BR></P></DIV>
<DIV></DIV><mailto:dev...@li...?subject=unsubscribe><mailto:dev...@li...><mailto:dev...@li...?subject=help><mailto:dev...@li...?subject=subscribe>
<DIV></DIV></mailto:dev...@li...?subject=subscribe></mailto:dev...@li...?subject=help></mailto:dev...@li...></mailto:dev...@li...?subject=unsubscribe></div><br clear=all><hr>STOP MORE SPAM with <a href="http://g.msn.com/8HMBEN/2728??PS=">the new MSN 8</a> and get 2 months FREE*</html>

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Michael C U. <mu...@cb...>]

On Fri, 16 Jan 2004, Daniel K. O. wrote:

> I don't see it as a big problem. There aren't too much cases when you
> really NEED to update the gui outside the main thread.

Updating the GUI in the main thread can cause noticable delays in the user
interface. The progress bar is a good example. If you update that from the
main thread, then every time the main thread has to repaint the progress
dialog, it's going to interrupt the user experience.

Animation and VR simulations that require rapid repainting of the display
are another area where you often don't want to tie up the main thread by
forcing it to handle the paint requests and such. The application can
become extremely unresponsive if the main thread has to handle such paint
intensive tasks.

Re: [Dev-C++] can't get dev-cpp to compile...

[P.T. W. M. <pt...@ea...>]

C++ has changed, and no longer uses the old style headers.  Use:

#include <iostream>
using namespace std;

".h" is nolonger used.

Patrick

At 15:04 16-01-04, Kovalan Muniandy wrote:

>Hi,
>
>I have just installed Dec-C++ on my Windows XP laptop. However, I can't 
>get to compile the project "Hello World". The compiler complains that 
>"iostream.h" is not found.
>
>I have tried looking into the Compiler options to make sure the include 
>directories are good, and they appear to be. Initially, it had c:\dev-_1~ 
>or something like that but I have reinstalled Dev-C++ in a eight width 
>friendly file folder called c:\devcpp\. So, the include directories point 
>to c:\devcpp\Include\G++;c:\devcpp\Include. The iostream.h is in the G++ 
>folder.
>
>What else could be wrong?
>
>Kovalan

[Dev-C++] can't get dev-cpp to compile...

[Kovalan M. <kov...@fu...>]

Hi,

I have just installed Dec-C++ on my Windows XP laptop. However, I can't=
 get
to compile the project "Hello World". The compiler complains that
"iostream.h" is not found.

I have tried looking into the Compiler options to make sure the include=

directories are good, and they appear to be. Initially, it had c:\dev-_=
1~
or something like that but I have reinstalled Dev-C++ in a eight width
friendly file folder called c:\devcpp\. So, the include directories poi=
nt
to c:\devcpp\Include\G++;c:\devcpp\Include. The iostream.h is in the G+=
+
folder.

What else could be wrong?

Kovalan=

Re: [Dev-C++] dll inspection tools?

[Daniel K. O. <dan...@ya...>]

Alvin Thompson wrote:

>hello,
>
>anyone know of any DLL inspection tools out there? what i want to do is
>look at a dll, figure out what functions/anything else it exports, and
>make my own version. is this possible?
>  
>

 nm name_of_your.dll | grep ' T _' | sed 's/.* T _//'



Daniel K. O.

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Goran <go...@de...>]

Dana petak 16. januar 2004. 18:02, Michael C Urban je napisao/la:
> My main gripe with FLTK. The widgets are uglier than just about anything I
> have ever seen. The icons and such look like a child drew them. FLTK 2.0
> is supposed to be skinnable so that problem will go away, but AFAIK, right
> now, FLTK is not skinnable.

Use eFLTK - fork of FLTK2 that is stable and have support for UTF8 and themes 
and many more...

Goran

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Goran <go...@de...>]

Dana petak 16. januar 2004. 20:57, Michael C Urban je napisao/la:
> Try to imagine running everything as managed code. Even low level system
> processes. That's what Longhorn is going to do. Whether the specs will be
> that high or not, I don't know. But they will definately be a lot higher
> than the specs for Windows XP.

=46rom some beta test you will need P4@2.6Ghz with at least 1024MB RAM. I t=
hink=20
that this will not be too much for 2007. But there is again one simple=20
question: If OS need that CPU power, what the hell applications need to do.=
=20
And forget about some easy database apps, think about simulations, 3d games=
,=20
3d rendering, image processing, ...=20

I donot beleive that thay will drop WinAPI too. MS Office will be the last=
=20
application that will be written in new API - they even donot use the same=
=20
GUI library ;)

As someone already said:
Your Windows session is over.
What do you want to play next?

Bye,
Goran

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Daniel K. O. <dan...@ya...>]

Michael C Urban wrote:

>On Fri, 16 Jan 2004, Daniel K. O. wrote:
>  
>
>>Actually, you just can't update the GUI from other threads.
>>    
>>
>Yeah... That's what "not thread safe" means.
>  
>


I don't see it as a big problem. There aren't too much cases when you 
really NEED to update the gui outside the main thread.
Say, if you're updating a progress bar for some task you're doing in a 
thread, eventually you'll get to 100%. Then, you usually want to do 
something else in your program. This is the moment you will need to 
synchronize with something else. If you're already doing the update 
inside the main thread, you'll probably won't need to lock other stufs.

I couldn't find more than a few specific real-world examples that would 
need threads to update the main GUI (but still can be written the other 
way to work with GTK+ on Windows), and wouln't need to synchronize with 
the rest of the program. Would be interesting if somebody show us some 
of these examples - and then forward it to the GTK+ developers.


Daniel K. O.

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[<or...@vp...>]

Michael C Urban wrote:
> I also don't think we are going to see a mass migration to Longhorn
> either. Longhorn is going to require some truly serious hardware to
> deliver acceptable performance. Microsoft has estimated that that by the
> time we see Longhorn, new PCs will have a dual core processor running at
> least 6 Ghz, a terabyte of hard disk space, at least 2 Gb of RAM, and a
> very powerful 3D graphics accelerator. If that's any indication about the
> mimimum hardware requirements Longhorn is going to need, it's going to be
> a tough sell to businesses and such who aren't always on the cutting edge
> of the technology curve. After all, remember that something like 30% of
> Windows users are still using Windows 98.

Like ME for example.
And I don't think I'll go any further than Windows XP, IF even I'll ever 
install that. I don't want an "operating system" (Longhorn), that 
consumes 6x times as much power as my PC provides now (Celeron 500 MHz) 
just by doing NOTHING (not to mention the stupidly uneconomical use of 
electricity). If Windows 98 will be totally out-of-date (as Windows 3.1 
is now), then I'll switch to Debian/Linux/KDE forever.

Oh, and to add something to the REAL subject: I recommend wxWindows.

--
Greetings,
   Balázs

Re: [Dev-C++] dll inspection tools?

[<or...@vp...>]

Alvin Thompson wrote:
> anyone know of any DLL inspection tools out there? what i want to do is
> look at a dll, figure out what functions/anything else it exports, and
> make my own version. is this possible?

ShowDep is a nice and feature-full tool, you can give it a try:
http://www.showdep.com

--
Greetings,
   Balázs

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Michael C U. <mu...@cb...>]

Try to imagine running everything as managed code. Even low level system
processes. That's what Longhorn is going to do. Whether the specs will be
that high or not, I don't know. But they will definately be a lot higher
than the specs for Windows XP.

On Fri, 16 Jan 2004, Daniel Glenfield wrote:

> I don't think that spec will be required. I really don't think that will be
> the case!
> and we still supply customers who request windows 3.1 bits and pieces!
>
>
> >From: Michael C Urban <mu...@cb...>
> >To: Daniel Glenfield <sp...@ho...>
> >CC: go...@de..., dev...@li...
> >Subject: Re: [Dev-C++] Offtopic: Advice on GUI to learn
> >Date: Fri, 16 Jan 2004 11:07:12 -0600 (CST)
> >
> >I also don't think we are going to see a mass migration to Longhorn
> >either. Longhorn is going to require some truly serious hardware to
> >deliver acceptable performance. Microsoft has estimated that that by the
> >time we see Longhorn, new PCs will have a dual core processor running at
> >least 6 Ghz, a terabyte of hard disk space, at least 2 Gb of RAM, and a
> >very powerful 3D graphics accelerator. If that's any indication about the
> >mimimum hardware requirements Longhorn is going to need, it's going to be
> >a tough sell to businesses and such who aren't always on the cutting edge
> >of the technology curve. After all, remember that something like 30% of
> >Windows users are still using Windows 98.
> >
> >Mike
> >
> >On Fri, 16 Jan 2004, Michael C Urban wrote:
> >
> > > As far as Longhorn, the latest word is that we won't see it until 2006,
> >or
> > > maybe even 2007. So the Win32 API is going to be the main API for
> >Windows
> > > for at least a few more years.
>
> _________________________________________________________________
> Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo
>
>

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Daniel G. <sp...@ho...>]

I don't think that spec will be required. I really don't think that will be 
the case!
and we still supply customers who request windows 3.1 bits and pieces!


>From: Michael C Urban <mu...@cb...>
>To: Daniel Glenfield <sp...@ho...>
>CC: go...@de..., dev...@li...
>Subject: Re: [Dev-C++] Offtopic: Advice on GUI to learn
>Date: Fri, 16 Jan 2004 11:07:12 -0600 (CST)
>
>I also don't think we are going to see a mass migration to Longhorn
>either. Longhorn is going to require some truly serious hardware to
>deliver acceptable performance. Microsoft has estimated that that by the
>time we see Longhorn, new PCs will have a dual core processor running at
>least 6 Ghz, a terabyte of hard disk space, at least 2 Gb of RAM, and a
>very powerful 3D graphics accelerator. If that's any indication about the
>mimimum hardware requirements Longhorn is going to need, it's going to be
>a tough sell to businesses and such who aren't always on the cutting edge
>of the technology curve. After all, remember that something like 30% of
>Windows users are still using Windows 98.
>
>Mike
>
>On Fri, 16 Jan 2004, Michael C Urban wrote:
>
> > As far as Longhorn, the latest word is that we won't see it until 2006, 
>or
> > maybe even 2007. So the Win32 API is going to be the main API for 
>Windows
> > for at least a few more years.

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

[Dev-C++] dll inspection tools?

[Alvin T. <al...@th...>]

hello,

anyone know of any DLL inspection tools out there? what i want to do is
look at a dll, figure out what functions/anything else it exports, and
make my own version. is this possible?

thanks,
alvin

-- 
Alvin Thompson

Navy: 34
Army: 6

Re: [Dev-C++] Dev-C++ compiling

[Zonnet <gko...@zo...>]

Hi,
if you're new to programming, I advice you to get the DevPack for
wxWindows. It should be available via on-line install in DevC++.
Otherwise please google for it. It's really easy and compiling wxWindows
yourselfs is not nice....!
wkr,
Gerke


Subrata Banerjee wrote:

>Hello,
>I'm new to programming. i shall be obliged if anybody help me
>how to compile wxWindows with Dev-C++.
>
>thanks in advance.
>
>i beg apology if i have annoyed anybody.
>
>thanks again.
>
>Subrata.
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>  
>

[Dev-C++] Re: Dev-C++ compiling

[Kevin B. <kev...@ma...>]

>I'm new to programming. i shall be obliged if anybody help me
>how to compile wxWindows with Dev-C++.


Don't. Use make instead.

Example of a batch file to do so:

set PATH=C:\Dev-Cpp;C:\Dev-Cpp\bin;%PATH%
set WXWIN=N:\Library\wxWindows
cd src\msw
make -f makefile.g95 clean
make -f makefile.g95 FINAL=1
cd ..\..\samples\minimal
make -f makefile.g95 cleanall
make -f makefile.g95 FINAL=1
pause


Change the paths as appropriate to your system.

Omit FINAL=1 to make a debug build.

--- Kevin

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Michael C U. <mu...@cb...>]

I also don't think we are going to see a mass migration to Longhorn
either. Longhorn is going to require some truly serious hardware to
deliver acceptable performance. Microsoft has estimated that that by the
time we see Longhorn, new PCs will have a dual core processor running at
least 6 Ghz, a terabyte of hard disk space, at least 2 Gb of RAM, and a
very powerful 3D graphics accelerator. If that's any indication about the
mimimum hardware requirements Longhorn is going to need, it's going to be
a tough sell to businesses and such who aren't always on the cutting edge
of the technology curve. After all, remember that something like 30% of
Windows users are still using Windows 98.

Mike

On Fri, 16 Jan 2004, Michael C Urban wrote:

> As far as Longhorn, the latest word is that we won't see it until 2006, or
> maybe even 2007. So the Win32 API is going to be the main API for Windows
> for at least a few more years.

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Michael C U. <mu...@cb...>]

My main gripe with FLTK. The widgets are uglier than just about anything I
have ever seen. The icons and such look like a child drew them. FLTK 2.0
is supposed to be skinnable so that problem will go away, but AFAIK, right
now, FLTK is not skinnable.

Other than that, it's a nice toolkit.

Mike

On Fri, 16 Jan 2004, Maya wrote:

> No one here has mentioned FLTK.
> How would you compare FLTK to wxWindows or FOX?
> What would be the biggest advantage / disadvantage over the other tool
> kits discussed in this thread? excluding WIN32.
>
> As a general rule, it is best to write code that is as portable as
> possible. I myself try to use the C++ STDs as much as I can. However,
> since what I do is to develop applications for UNIX machines and now
> MSW, speed in this case can be viewed as a challenge, but as I always
> say, "Either the user waits three nanoseconds or we spent $30K on
> restructuring the app."; we all know what the answer is to that one.
> As I am trying to implement a better GUI to up coming applications, I
> have been doing some research and have found that the FLTK mailing list
> team is very dynamic as well as the FOX team. There is a lack of
> documentation for both libraries, but as someone said, "you can always
> have a look at the code".
>
> What I am looking for in a GUI tool kit are three things. One,
> portability. As I said before I want the freedom to compile here, there
> and any where. Good bye MFC!! and other MSW-only gui tool kits
> Second, it must be a FSF tool kit. I want provide the quality of service
> and professionalism the customers are used to, with out the problem of
> having to by licenses for this machine or that one or another; savings
> in this area will substantially lower the price of the app. development;
> making me more competitive / marketable. Good bye Qt!!
> Third, but not least, it must be a C++ tool kit... mmm ... or have C++
> bindings like gtk+ [gtkmm]
>
> Stability, learning curve and other aspects that are to be considered
> will be looked at when and only when the above conditions are met.
>
> I would like to thank you in advance for you help, and any other member
> of the Dev-Cpp mailing list that might be interested in pitching in the.
>
> PD
> Are there any programers in this list that live in the Toronto are? S/He
> must be fluent in C++ and Dev-Cpp.
>
>
> mu...@cb... wrote:
>
> >On Thu, 15 Jan 2004, Oliver Brandt wrote:
> >
> >
> >
> >>looking forward into the future microsoft=B4s winapi is dead. Because
> >>"Longhorn" has no winapi anymore. I don=B4t know what comes then
> >>but you have to learn a new api. So I think wxwindows is very easy
> >>to use, it=B4s a crossplattform toolkit and is=B4s very mature.
> >>
> >>
> >
> >Well, the Win32API is depricated. But it will be around for awhile yet.
> >Microsoft can't just get rid of it with Longhorn because that will break
> >Legacy apps.
> >
> >But wxWindows is broken when the Win32 API goes away too, unless it is
> >completely rewritten on the Windows platform to use the WinFX API. All
> >wxWindows does is wrap native Win32 API functions in classes and such.
> >
> >
> >-------------------------------------------------------
> >The SF.Net email is sponsored by EclipseCon 2004
> >Premiere Conference on Open Tools Development and Integration
> >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> >http://www.eclipsecon.org/osdn
> >_______________________________________________
> >Dev-cpp-users mailing list
> >Dev...@li...
> >TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
> >
>
> --
>
> FYI
> http://www.astro.umd.edu/~marshall/abbrev.html
>
> E-Mail Policy
> http://www.vif.com/users/escalante/Email_Policy.html
>
> * You cannot exercise your power to a point of humiliation.
>                                - Jean Chretien
>
> * The media's the most powerful entity on earth. They have the
>   power to make the innocent guilty and to make the guilty
>   innocent, and that's power.
>                                 - Malcom X
> * "Innocent until proven guilty", no... not in Canada!!
>
>
>

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Michael C U. <mu...@cb...>]

Well, like I said, the Win32 API will eventually go away. But it's going
to go away for a long time because Microsoft can't afford to break all of
the legacy applications that are out there.

As far as Longhorn, the latest word is that we won't see it until 2006, or
maybe even 2007. So the Win32 API is going to be the main API for Windows
for at least a few more years.

But if you want to write WinFX apps, like I said, .NET is a subset of
WinFX. According to Microsoft, "the best way for your apps to be ready for
Longhorn and WinFX, and the best way for you as a programmmer to be ready
for WinFX, is to write .NET apps today."

So what you can do if you want to learn WinFX is download the .NET SDK
from Microsoft. And then after you have played with it a bit, you can see
for yourself (as I did), how much it sucks and how bad its performance is,
and then you can switch to Java.

Mike

On Fri, 16 Jan 2004, Daniel Glenfield wrote:

> Personally I'm at a bit of a quandary (thanks Dictionary.com) as I'm sure
> many new Windows programmers are. Do we work hard to learn the old APIs or
> do we hold off for the WinFX api?
>
> Does anyone know of a good site with WinFX information? Yes I could google
> it but there's no guarantee I will find the best site. Google isn't a real
> world programmer.
>
>
>
>
> >From: Michael C Urban <mu...@cb...>
> >To: Daniel Glenfield <sp...@ho...>
> >CC: go...@de..., dev...@li...
> >Subject: Re: [Dev-C++] Offtopic: Advice on GUI to learn
> >Date: Fri, 16 Jan 2004 03:07:23 -0600 (CST)
> >
> >On Fri, 16 Jan 2004, Daniel Glenfield wrote:
> >
> > > You can create a window in 5 lines, but won't that be very high level?
> >With
> > > the windows API you have other things to set up. Or is there a more
> >detailed
> > > version that takes 30 lines of code?
> >
> >With the Windows API, you have to set up a lot of things manually that the
> >toolkit's class will set up for you automatically. Example, if you want to
> >load an image in a window and be able to scroll that image, the toolkit
> >has a class that will automatically set up the scrollbars for you. With
> >the Windows API, the scrollbars have to be manually programmed to
> >determine how far their range should be, how far it should move with each
> >click, how far it should move the image with each click, where the image
> >ends so that it doesn't scroll past the end, etc. You also have to
> >manually program the scrollbar movement and set its position. And that
> >won't even give you the ability to use the arrow keys, the page up/page
> >down keys, or the scroll wheel. If you want those, it's more manual
> >programming. The result is that it can literally take 80 or 90 lines of
> >code just to get a decent scrollbar using the Windows API. Using a high
> >level toolkit, you can probably do it in less than 10. In Java Swing, I
> >just did it with 3 lines of code. Literally, it took me 3 lines of code to
> >do what takes about 90 lines of code to do using the Windows API.
> >
> >So yes, you are working at a much higher level with a toolkit. But
> >generally, that is a good thing. It lets you concentrate on what you want
> >to do (display a scrollable image), rather than how to do what you want to
> >do (implement a bunch of math formulas and such to determine how far the
> >image should scroll with each mouse click on a scroll arrow, how far the
> >scrollbar should move in response, etc.)
> >
> >Mike
> >
>
> _________________________________________________________________
> It's fast, it's easy and it's free. Get MSN Messenger today!
> http://www.msn.co.uk/messenger
>
>

[Dev-C++] Dev-C++ compiling

[Subrata B. <s.b...@vs...>]

Hello,
I'm new to programming. i shall be obliged if anybody help me
how to compile wxWindows with Dev-C++.

thanks in advance.

i beg apology if i have annoyed anybody.

thanks again.

Subrata.

RE: [Dev-C++] Hello + problem in concept_check.h

[Daniel G. <sp...@ho...>]

Ah I've not the read the replies to this but I think it is because 
underscore-underscore is not allowed in C++ standards or not recommended at 
least because some compilers use types with __XYZ and there may be problems 
if you #define one with the same name.

or something ;)


>From: "J.R D'Amore" <jr...@be...>
>To: dev...@li...
>Subject: [Dev-C++] Hello + problem  in concept_check.h
>Date: Thu, 15 Jan 2004 13:53:56 -0600
>
>Hello everybody !
>
>I am starting to study Dev-C++ cos we want to move our Visual C++ code to 
>such a nice freeware IDE.
>
>I have a problem when trying to compile one of my CPP project, always the 
>same, concerninig the following declaration in the concept_check.h template 
>file:
>
>                     #define __glibcpp_function_requires(..)
>
>The message  I have is the following :
>
>                     badly punctuated parameter list in '#define'
>
>Any help would be very much appreciated...
>
>Thanks
>
>JR

_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Maya <Esc...@ne...>]

No one here has mentioned FLTK.
How would you compare FLTK to wxWindows or FOX?
What would be the biggest advantage / disadvantage over the other tool 
kits discussed in this thread? excluding WIN32.
 
As a general rule, it is best to write code that is as portable as 
possible. I myself try to use the C++ STDs as much as I can. However,  
since what I do is to develop applications for UNIX machines and now 
MSW, speed in this case can be viewed as a challenge, but as I always 
say, "Either the user waits three nanoseconds or we spent $30K on 
restructuring the app."; we all know what the answer is to that one.
As I am trying to implement a better GUI to up coming applications, I 
have been doing some research and have found that the FLTK mailing list 
team is very dynamic as well as the FOX team. There is a lack of 
documentation for both libraries, but as someone said, "you can always 
have a look at the code".

What I am looking for in a GUI tool kit are three things. One, 
portability. As I said before I want the freedom to compile here, there 
and any where. Good bye MFC!! and other MSW-only gui tool kits
Second, it must be a FSF tool kit. I want provide the quality of service 
and professionalism the customers are used to, with out the problem of 
having to by licenses for this machine or that one or another; savings 
in this area will substantially lower the price of the app. development; 
making me more competitive / marketable. Good bye Qt!!
Third, but not least, it must be a C++ tool kit... mmm ... or have C++ 
bindings like gtk+ [gtkmm]

Stability, learning curve and other aspects that are to be considered 
will be looked at when and only when the above conditions are met.

I would like to thank you in advance for you help, and any other member 
of the Dev-Cpp mailing list that might be interested in pitching in the.

PD
Are there any programers in this list that live in the Toronto are? S/He 
must be fluent in C++ and Dev-Cpp.


mu...@cb... wrote:

>On Thu, 15 Jan 2004, Oliver Brandt wrote:
>
>  
>
>>looking forward into the future microsoft´s winapi is dead. Because
>>"Longhorn" has no winapi anymore. I don´t know what comes then
>>but you have to learn a new api. So I think wxwindows is very easy
>>to use, it´s a crossplattform toolkit and is´s very mature.
>>    
>>
>
>Well, the Win32API is depricated. But it will be around for awhile yet.
>Microsoft can't just get rid of it with Longhorn because that will break
>Legacy apps.
>
>But wxWindows is broken when the Win32 API goes away too, unless it is
>completely rewritten on the Windows platform to use the WinFX API. All
>wxWindows does is wrap native Win32 API functions in classes and such.
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>  
>

-- 

FYI
http://www.astro.umd.edu/~marshall/abbrev.html

E-Mail Policy
http://www.vif.com/users/escalante/Email_Policy.html

* You cannot exercise your power to a point of humiliation.
                               - Jean Chretien

* The media's the most powerful entity on earth. They have the 
  power to make the innocent guilty and to make the guilty 
  innocent, and that's power. 
                                - Malcom X
* "Innocent until proven guilty", no... not in Canada!!

Re: [Dev-C++] Offtopic: Advice on GUI to learn

[Daniel G. <sp...@ho...>]

Personally I'm at a bit of a quandary (thanks Dictionary.com) as I'm sure 
many new Windows programmers are. Do we work hard to learn the old APIs or 
do we hold off for the WinFX api?

Does anyone know of a good site with WinFX information? Yes I could google 
it but there's no guarantee I will find the best site. Google isn't a real 
world programmer.




>From: Michael C Urban <mu...@cb...>
>To: Daniel Glenfield <sp...@ho...>
>CC: go...@de..., dev...@li...
>Subject: Re: [Dev-C++] Offtopic: Advice on GUI to learn
>Date: Fri, 16 Jan 2004 03:07:23 -0600 (CST)
>
>On Fri, 16 Jan 2004, Daniel Glenfield wrote:
>
> > You can create a window in 5 lines, but won't that be very high level? 
>With
> > the windows API you have other things to set up. Or is there a more 
>detailed
> > version that takes 30 lines of code?
>
>With the Windows API, you have to set up a lot of things manually that the
>toolkit's class will set up for you automatically. Example, if you want to
>load an image in a window and be able to scroll that image, the toolkit
>has a class that will automatically set up the scrollbars for you. With
>the Windows API, the scrollbars have to be manually programmed to
>determine how far their range should be, how far it should move with each
>click, how far it should move the image with each click, where the image
>ends so that it doesn't scroll past the end, etc. You also have to
>manually program the scrollbar movement and set its position. And that
>won't even give you the ability to use the arrow keys, the page up/page
>down keys, or the scroll wheel. If you want those, it's more manual
>programming. The result is that it can literally take 80 or 90 lines of
>code just to get a decent scrollbar using the Windows API. Using a high
>level toolkit, you can probably do it in less than 10. In Java Swing, I
>just did it with 3 lines of code. Literally, it took me 3 lines of code to
>do what takes about 90 lines of code to do using the Windows API.
>
>So yes, you are working at a much higher level with a toolkit. But
>generally, that is a good thing. It lets you concentrate on what you want
>to do (display a scrollable image), rather than how to do what you want to
>do (implement a bunch of math formulas and such to determine how far the
>image should scroll with each mouse click on a scroll arrow, how far the
>scrollbar should move in response, etc.)
>
>Mike
>

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger