|
Yes, you are right, the class is not initialized,
but, the amazing fact is that calling another function
from the class, through "this" pointer work!!!!!
Is like a virtual table exist, for a class uninstantiated!!!!
 - maybe I should verify this with another compiler!!
|
|
|
|
|
You really will want to make your entry point function a static function, unless there is no member variables in your class, then it wont matter.
The function V-Table always exists for a C++ object, that is why your non-static member function succeeded, however, the moment that you try to use a member variable from this function, without an instantiated object, your program will crash because no memory has been allocated to this object, and there is no valid this pointer sent into the function.
If you were to try this example with teh get_data member funtion as the entry point, it would crash on you:
<br />
#include "stdafx.h"<br />
<br />
class entry<br />
{<br />
int m_data;<br />
public:<br />
static int point()<br />
{<br />
return 0;<br />
}<br />
<br />
int get_data()<br />
{<br />
return m_data;<br />
}<br />
<br />
};<br />
<br />
int main()<br />
{<br />
entry::point();<br />
<br />
entry x;<br />
x.get_data();<br />
<br />
return 0;<br />
}<br />
With this is mind, your static member function should instantiate a class object for you to continue with your plans.
|
|
|
|
|
kilowatt wrote:
The function V-Table always exists for a C++ object, that is why your non-static member function succeeded,
Thanks, I doesn't know this. So, no misterys here! 
kilowatt wrote:
however, the moment that you try to use a member variable from this function, without an instantiated object, your program will crash because no memory has been allocated to this object, and there is no valid this pointer sent into the function.
You again are right.
So, my questions are clear now. Thanks a lot for your patience.
Regards.
|
|
|
|
|
Well, someone here recently remarked that its better to speak up and find out you're wrong and learn something... 
I was testing with just a global foo() fn, and had to force linkage if I removed main, but I see now this can work.
I wasn't able to track down anything on the ability to manually initialize the c runtime though, and would like to know if thats possible. FWTW I did stumble on a '96 MSJ article by Matt Pietrek where he outlines how to _avoid_ using the CRT - search for TINYCRT in MSDN - win32 routines are used instead.
|
|
|
|
|
I am concerned about the following:
As long as in the linker options, I can set the program entry point,
and - I tested personally - this can be any function, with any prototype
(I mean not just main standard prototype), I wonder if is a way to set
as entry point a function with prototype like
AClass myClassInstance;
i.e a class type (user defined data type).
I put the question because I couldn't remember where I found a topic about
the fact that C++ doesn't really need main() function to work (was certainly
a discution about OO Programming and OO nature of C++)
Can anybody help? Does anyone know something similar?
Regards.
|
|
|
|
|
C++, like C, requires a main function for its entry point.
Yes, you can put a different function in the linker settings but I think its ignored for executables unless its just a question of resolution (i.e. wWinMainCRTStartup for unicode windows apps).
The key here is that you're linking with a standard runtime library (CRT) that has startup and exit code that will call your main routine after certain operations are performed (init static vars etc).
The 'nostub' programs you speak of are built with non-standard libraries and are I think targeted at embedded code that wants to bypass certain lib code for compatibility reasons.
It should be said that the reason for main is to maintain (no pun) the ability for C programs to be compiled. Would you rather go with a java construct where the 'main' class contains a defined entry point? Or is that still a restriction? I won't fight you if your argument is that that is more 'object oriented' - but until I get smarter that Stroustrup (note, I've almost got his hairstyle ) I'll try and deal with it.
|
|
|
|
|
I need a file open dialog with the following attributes:
#1 - Floppy drive access disabled.
#2 - Drag & Drop disabled within the file/folder list(s).
#3 - Context sensitive menu disabled.
#4 - Runs on Windows 95/98/Me.
Can this be done with the standard Microsoft CFileDialog class? If so, how? (I've read several CFileDialog sub-classing articles and none provide any clue to any of these issues.) If this is not possible with the standard dialog, does anyone know of a class that provides this functionality so I don't have to re-invent the wheel?
If anyone is interested in why I need this, read below...
Concept - My application is a control for a piece of industrial machinery. It provides a GUI to the operator as well as machine logic and high speed messaging with proprietary motion control modules for the machines axes. It runs on an industrial PC with a flat panel touch screen and a Texas Industrial pointing device. The operator needs to load new program files for each piece of raw stock that comes to the machine. Right now I am using the standard CFileDialog and have the following problems:
#1 - Floppy drive access is very slow and drags down system performance, when this happens the proprietary motion control modules' watchdog timers time out and shutdown the control. We tell everyone not to use floppies directly in the control software, but some never learn and I'd like to stop them.
#2 - Because the touch screen and industrial pointing devices are... well... industrial, they don't provide a good high resolution consistent method of handling smallish items (like files/folders in a CListCtrl) and heavy-handed operators accidently drag files/folders and drop them into other folders and lose them.
#3 - The machine operators have no need of the items in the context sensitive menu and can only get themselves in trouble with these commands. I'd like to eliminate the possibility.
#4 - Unfortunately the drivers for the proprietary motion control modules run ONLY under Windows 95/98/Me and many of our current machines in the field are running Windows 95, so any solution MUST run on it.
Problems #2 and #4 are the most important, #1 and #3 are icing on the cake!
Mike Mullikin
"Programming is like sex. One mistake and you have to support it for the rest of your life." - Michael Sinz
|
|
|
|
|
I'd craft my own, using a combo box of hard disks, a folder listbox and a files list box, much like the old style File Open dialog. You can also auto-filter for files of a specific type that make sense to your app.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I don't think CFileDialog is as customizable as you need. Xiaolong Wu has written a CFileDialog clone for which he provides the source code. Maybe you can download it and modify it to suit your needs (he even points this in his article as a major reason for having written the clone).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I am no expert, but why not just use a simple list control that lists all the available programs, or may be a series of list controls if the programs are grouped in some way. It seems to me the operator does not need to have any knowledge of where the programs are located on disk, he/she just needs the ability to choose the one that is required for the current job.
Use the KISS (Keep It Simple, Stupid) method. Don't give the operator any more functionality than what he needs to do the job, it just confuses most of them.
---
Sonork 100.11743 Chicken Little
It may be that your sole purpose in life is simply to serve as a warning to others.
|
|
|
|
|
PJ Arends wrote:
I am no expert, but why not just use a simple list control that lists all the available programs, or may be a series of list controls if the programs are grouped in some way. It seems to me the operator does not need to have any knowledge of where the programs are located on disk, he/she just needs the ability to choose the one that is required for the current job.
The problem is that in this industry (structural steel fabrication) a fabricator will typically have dozens (maybe hundreds) of separate projects running through their shop at any given time. Each project can have dozens of phases that get done individually. Each phase can have several hundred or even several thousand individual unique parts. Some projects can last several years. Most fabricators use a somewhat elaborate (and nearly always proprietary) network folder tree structure to keep the projects/phases/parts organized. The strength of our machinery is that it requires virtually no setup or reconfiguring to switch from part to part and therefore fabricators tend to send parts at it in no particular order (as it relates to specific projects/phases) and the operator must navigate thru this maze of folders to find the correct part.
PJ Arends wrote:
Use the KISS (Keep It Simple, Stupid) method. Don't give the operator any more functionality than what he needs to do the job, it just confuses most of them.
I agree 100% and have argued this point on this very topic, but fabricators are also a pig-headed group and demand this flexibility.
It looks like I'll have to roll my own or live with it the way it is.
Mike Mullikin
"Programming is like sex. One mistake and you have to support it for the rest of your life." - Michael Sinz
|
|
|
|
|
Add another vote for roll your own. I have dealt with touchscreens also and they present some challenges. Although they may look clunky, buttons must often be a bit larger so that people wearing gloves can press them.
I would make a dialog with a listbox for the files and two large up down arrow buttons for selection. It is easy to write logic for filling the list with files and additional logic for directory navigation is not too tough.
Good luck.
|
|
|
|
|
The roll-your-own solutions mentioned above sound like your best bet, but for a quick solution, you can remove the OFN_EXPLORER style from CFileDialog::m_ofn.Flags. This will make it an old-style dialog, with no support for drag & drop or property menus.
CFileDialog dlgFile(TRUE);
dlgFile.m_ofn.Flags &= ~OFN_EXPLORER;
dlgFile.DoModal();
This page describes a way that might work for hiding the a: drive.
Setting up windows to use large fonts might make this all easier to use via a touch screen.
farewell goodnight last one out turn out the lights Smashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
Hi everyone, im trying to display an icon within a button so i inserted
the code below:
void CButtonDlg::OnButton1()
{
m_btn1.SetIcon(IDI_ICON1);
}
But it an error occurs : error C2664: 'SetIcon' : cannot convert parameter 1 from 'const int' to 'struct HICON__ *' (new behavior; please see help)
CAN ANYONE HELP ME? THANK YOU IN ADVANCE ! 
|
|
|
|
|
There are lots of articles in CP about buttons.
Mazy
Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without
|
|
|
|
|
SetIcon accepts an HICON (a handle to an icon) rather than a resource identifier. Use AfxGetApp()->LoadIcon(...) to obtain the icon first.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi,
I've a treeCtrl, with many items in it; i want that some of them have an image and other don't...
but if I don't specify an image, thr ctrl selects the first image in the image list...
I tryed using states instead of images, but only 16 states are allowed, and I need more...
Someone has any idea?
thanks
|
|
|
|
|
Have you tried setting -1 as the nImage index?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
yes... but it works wrong: if I defined a 32x32 image, it leaves a 32x32 white space...
|
|
|
|
|
I've got a dialog based application and I created my own menu in it. However, if the user does File | Save, it doesnt automatically call the Serialize funtion like an sdi/mdi app would, and i cant find the code where the automation takes place in an sdi/mdi. How do I do it?
-Raffi
The truth about C++
|
|
|
|
|
MSDN
The DECLARE_SERIAL macro is required in the declaration of classes that will support serialization, as shown here:
class CPerson : public CObject
{
DECLARE_SERIAL( CPerson )
};
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
(In VC++ 6) I create a CListCtrl control and want it show a tooltip when user lay the cursor on its each item. So I set the list control style to LVS_EX_TRACKSELECT and define a function to handle the LVN_HOTTRACK notify.
The problem is the program work fine in debug config compile version but got error in release version. The error is come from the LVN_HOTTRACK function. (without it, the program got no error)
Anyone please give me some suggestions.
Thank you.
|
|
|
|
|
Could you please post the code for the LVN_HOTTRACK handler?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
ON_NOTIFY ( LVN_HOTTRACK, IDC_lstctl_THR, OnHottrackNotify )
...
BOOL CPXP_MainDlg::OnHottrackNotify ( NMLISTVIEW * pNMLV )
{
return (FALSE);
}
(I put only 'return' to test the function, and it comeout fail)
|
|
|
|
|
That routine isn't a notify routine. It doesn't have all the arguments and what arguments it does have are wrong. The proper form is...
afx_msg void memberFxn( NMHDR * pNotifyStruct, LRESULT * result );
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
