Where should pointers to structs be created?

Hello,

I have several win procs creating their own widget(s). Often, one winproc displays only one widget along with other necessary program functionality.  So suppose I want to display a drop down list box, I create a pointer to a
ddlb object (or structure) and then I call a “new ddlb()” function so it can return a pointer to this object residing in heap… like this:

 

LRESULT CALLBACK_WP_DDLB( HWND hwnd, long message, WPARAM wParam, LPARAM lParam )
{
static ddlb* objDdlb1 = NULL; 

switch(message)
 {
  case KM_CREATE:
   objDdlb1 = DDLB_newDdlb(MEM_LAST_POS);

 DDLB_show_ddlb (objDdlb1);    

  // ... other code

  break;

 

  //... other code



  case KM_DESTROY:

  free(objDdlb1); 

  break;

  }

return KERNEL_DefWindowProc(hwnd, message, wParam, lParam);

}

Now, earlier programmation would simply call the DDLB_show_ddlb (objDdlb1) function and display the dropdown list box with hard coded values for its position, color and so forth. The only thing the DDLB_newDdlb(MEM_LAST_POS) function used
to do was set up a couple of members such as the maximum viewable items and stuff like that. But all to say that no position or color variables were set up in the DDLB_newDdlb() function. So deep in the ddlb.c code when it came time to display the drop
down list box, well all its elements such as text color, text positions, frames and so forth were hard coded to a certain position and color and thats it…. I really couldn’t change anything…. unless I would go and change those hard coded values
ofcourse… which is a pain for me or whoever one day is using this module.

So now, I have decided that the  DDLB_newDdlb() function would set up all of these hardcoded values through struct members instead. So here is the  DDLB_newDdlb() function: 

ddlb* DDLB_newDdlb(

unsigned short menu_entry_mode) 
{

ddlb* oBjDdlb; 
oBjDdlb = malloc (sizeof (struct tag_ddlb));


// Background positions for ddlb
oBjDdlb->bkg_flash_page = SN_(60, 70);    // SN_() Function not showed. Returns 60 if 1.5"LCD else return 70 if 2.0" LCD 
oBjDdlb->y_l_bkg_flash_page_pos = SN_(50,50); 
oBjDdlb->y_f_bkg_flash_page_pos = SN_(132,132);


//... other set ups here



return oBjDdlb;

}

So since DDLB_show_ddlb (objDdlb1) function carries in the pointer to the ddlb object, we can see that for example the DDLB_show_ddlb (objDdlb1) function will have access to any of the three (3) background members shown above. Now if ever the programmer
wants to change the bkg_flash_page, he can call a method which overrides the default values set in the DDLB_newDdlb() function.. like this:

 

============================================================================================Window Procedure

LRESULT CALLBACK_WP_DDLB( HWND hwnd, long message, WPARAM wParam, LPARAM lParam )

{
static ddlb* objDdlb1 = NULL; 

switch(message)
 {
  case KM_CREATE:
   objDdlb1 = DDLB_newDdlb(MEM_LAST_POS);

   DDLB_OVR_SetBbkgFlashPage(obj_ddlb, 61, 71); // Overrides the bkg flash page

   DDLB_show_ddlb (objDdlb1);          

  // ... other code

  break;

  

  //... other code



  case KM_DESTROY:

  free(objDdlb1); 

  break;

  }

return KERNEL_DefWindowProc(hwnd, message, wParam, lParam);

}



=========================================================================================ddlb.h



#ifndef DDLB_H

#define DDLB_H



typedef struct tag_ddlb             

{           

unsigned short menu_entry_mode;

enum eFLASH_BLK bkg_flash_page;  

unsigned short y_l_bkg_flash_page_pos;  

unsigned short y_f_bkg_flash_page_pos;       

//.... other members here



}



=========================================================================================ddlb.c

ddlb* DDLB_newDdlb(unsigned short menu_entry_mode) 

{

ddlb* oBjDdlb; 

oBjDdlb = malloc (sizeof (struct tag_ddlb));



oBjDdlb->menu_entry_mode = menu_entry_mode;



// Background positions for ddlb

oBjDdlb->bkg_flash_page = SN_(60, 70);  

oBjDdlb->y_l_bkg_flash_page_pos = SN_(50,50); 

oBjDdlb->y_f_bkg_flash_page_pos = SN_(132,132);



//... other set ups here



return oBjDdlb;

}



void DDLB_OVR_SetBbkgFlashPage(ddlb *obj_ddlb,

enum eFLASH_BLK bkg_flash_page_lcd_15, enum eFLASH_BLK bkg_flash_page_lcd_20)

{

oBjMn->bkg_flash_page = SN_(bkg_flash_page_lcd_15, bkg_flash_page_lcd_20);

}

So as you can imagine how large the struture declaration and the DDLB_newDdlb() function is when I added all the possible colors and position attributes that need to to be set for this ddlb object. In an earlier post I assumed that this was
the best way for me. So I continued and now this is my ddlb struct today with all attributes except for the ones involving color:

 

typedef struct tag_ddlb             

{           

             // General

unsigned char gso_idx;                          // Background flash page props
unsigned short menu_entry_mode;  
unsigned short LKsrc__F1; 
unsigned short LKsrc__F2;  
unsigned short LKsrc__F3;  

             // Background flash page  
enum eFLASH_BLK bkg_flash_page;  
unsigned short y_l_bkg_flash_page_pos;  
unsigned short y_f_bkg_flash_page_pos;  
             // ddlb up state icon
char up_ddlb_bmap_name[17];   
char up_ddlb_ico_num[17];   
unsigned char x_up_ddlb_pos;   
unsigned char y_up_ddlb_pos;   
             // ddlb down state icon

char dwn_ddlb_bmap_name[17];   
char dwn_ddlb_ico_num[17];   
unsigned char x_dwn_ddlb_pos;   
unsigned char y_dwn_ddlb_pos;   
             // ddlb sections
char list_sect_bmp_name[17];   
char list_sect_ico_num[17];   
unsigned char x_list_sect_pos;   
unsigned char y_list_sect_pos;   
             // hi lighting plate
char itm_hlight_plate_bmap_name[17];  
char itm_hlight_plate_ico_num[17];  
unsigned char x_itm_hlight_plate_pos0;  
unsigned char y_itm_hlight_plate_pos0;  
unsigned char y_itm_hlight_plate_pos1;  
unsigned char y_itm_hlight_plate_pos2;  
unsigned char y_itm_hlight_plate_pos3;  
unsigned char y_itm_hlight_plate_pos4;  
unsigned char y_itm_hlight_plate_pos5;  
            // list text item pos
char txt_list_item_font[17];   
unsigned char x_txt_list_item_pos0;  
unsigned char y_txt_list_item_pos0;  
unsigned char y_txt_list_item_pos1;  
            // On text display props
char on_dwn_txt_font[17];   
char on_dwn_txt[17];    
unsigned char x_on_dwn_txt_pos;  
unsigned char y_on_dwn_txt_pos;   
            // Button Props    
char but_bmp_name[17];   
enum eMBX_SET_NUM but_set_num;  
char alt_but_ico_num[17];   
char but_bmp_font[17];   
char but1_lab1[17];    
char but1_lab2[17];    
char but1_lab3[17];    
char but1_ico1_bmp_name[17];   
char but1_ico2_bmp_name[17];   
char but1_ico1[17];    
char but1_ico2[17];    
unsigned but1_left_border;   
unsigned but1_top_border;   
unsigned short x_but4_pos;     
unsigned short y_but4_pos;     
             // User message props...   
char user_msg_font[17];   
unsigned short x_user_msg_pos[3];  
unsigned short y_user_msg_pos[3];   
unsigned char enable_qck_msg;   
char quick_msg[17];           
             // expanding arrow icon    
char expd_arrow_bmp_name[17];  
char expd_arrow_ico_num[17];   
unsigned short x_expd_arrow_pos;  
unsigned short y_expd_arrow_pos;      
enum eFLASH_BLK flash_page_msb_bkg_expd_arrow; 
unsigned char mema_csb_dyn_bkg_expd_arrow; 
unsigned char mema_lsb_dyn_bkg_expd_arrow;  
             // Selected item arrow (Red arrow) 
char slct_itm_arrow_bmp[17];   
char slct_itm_arrow_ico_n[17];    
unsigned short x_slct_itm_arrow_pos;  
unsigned short y_slct_itm_arrow_pos;        
             // Up stream items arrow 
char up_stream_itm_arrow_bmp[17];  
char up_stream_itm_arrow_ico_n[17];   
unsigned short x_up_stream_itm_arrow_pos; 
unsigned short y_up_stream_itm_arrow_pos;     
           // Down stream items arrow 
char dwn_stream_itm_arrow_bmp[17];  
char dwn_stream_itm_arrow_ico_n[17];    
unsigned short x_dwn_stream_itm_arrow_pos;  
unsigned short y_dwn_stream_itm_arrow_pos;  
}

 

One like me, is to ask himself… is there something wrong with this picture? As you see the above structure is for the ddlb object, well my structs for the PC , PBARS, LB and other objects are pretty much similar to this one. I would
say mayby 70% similar. In other words in the structures for PC, PBARS, LB and others you would find members such as:

===========================================================================

                                                                       
 // Background flash page
enum eFLASH_BLK bkg_flash_page;
unsigned short y_l_bkg_flash_page_pos;
unsigned short y_f_bkg_flash_page_pos;  

                                                                      
// On text display props
char on_dwn_txt_font[17];
char on_dwn_txt[17];
unsigned char x_on_dwn_txt_pos;
unsigned char y_on_dwn_txt_pos;   

                                                                        //
Button Props
char  but_bmp_name[17];
enum eMBX_SET_NUM but_set_num;
char alt_but_ico_num[17];
char but_bmp_font[17];
char but1_lab1[17];
char but1_lab2[17];
char but1_lab3[17];
char but1_ico1_bmp_name[17];
char but1_ico2_bmp_name[17];
char but1_ico1[17];
char but1_ico2[17];
unsigned  but1_left_border;
unsigned but1_top_border;
unsigned short x_but4_pos;         
unsigned short y_but4_pos;         
                                                                      
 // User message props…
char user_msg_font[17];
unsigned short x_user_msg_pos[3];
unsigned short y_user_msg_pos[3];  
unsigned char enable_qck_msg;
char quick_msg[17];   

                                                                    
// Selected item arrow (Red arrow) 
char slct_itm_arrow_bmp[17];
char slct_itm_arrow_ico_n[17];  
unsigned short x_slct_itm_arrow_pos;
unsigned short y_slct_itm_arrow_pos;        

==================================================================

In this forum, within my posts, we have already spoken alot about grouping data members in different structs.  So for example, lets take the members for the user messaage which is pretty common in all my widget structures… here it is:

 // User message props…
char user_msg_font[17];
unsigned short x_user_msg_pos[3];
unsigned short y_user_msg_pos[3];  
unsigned char enable_qck_msg;
char quick_msg[17];   

where I thought of declaring and typedefing a struct called “tag_user_msg” somewhere in a common header file and including it in ddlb.h, like this:

 

typedef struct tag_user_msg

{

char user_msg_font[17]; 

unsigned short x_user_msg_pos[3]; 

unsigned short y_user_msg_pos[3]; 

unsigned char enable_qck_msg; 

char quick_msg[17]; 

}um;

 

So this way in my ddlb strut I would only have:

um*       user_msg;

Now this would not minimize the size of the DDLB_newDdlb() function since all members still have to be innitialized, but it would certainly decrease the number of members in my ddlb structure. So if I do the latter for every property, I would
therefore have “14 pointer to structs” similar as the um* one…  in my ddlb structure right!

The only thing I don’t get with everything I have said here, is where am I supposed to malloc all of these pointer to structs?

A) In the WM_CREATE handler of the win proc… before the DDLB_newDdlb(…) function? If so, this would mean that I would have 15 mallocs (14 pointers to struct + 1 ddlb pointer) in the WM_CREATE  handler and would have to pass in all
15 “pointers to structs” in the DDLB_newDdlb(…) function and so I would end up having 15 parameters ????  yuk!  Then free all of these 15 pointers at the WM_DESTROY handler….   yuk!  >>>> I say yuk because,
say I have 3 widgets in the same window procedure…. so then I would have 45 mallocs in the WM_CREATE handl……   ooooohh forget this option just thinking about it I am getting a headache!!!!

B) In the DDLB_newDdlb(…) function?  This would mean that I would malloc the ddlb plus all the other pointers to structs. Then I wuld have to create a function to be called at the WM_DESTROY handler to free all of these. This is a possible solution….
I think! What do you think?

C) Or use Inheritance/polymorphism for C>>>>  http://www.codeproject.com/KB/cpp/InheritancePolymorphismC.aspx  

This option is sort of difficult for me because I used to do examples in VC++ on polymorphism and inheritance from samples in a C++ book, but it seemed so much more simpler doing it in C++. Here I would have to brush up on function pointers also. And furthermore,
there would be alot more members in my structs since I would have to store the function pointers aswell. But what worries me the most is if you read the article til the end, some folks disapprove using inheritance and polymorphism for C programming. So
I don’t know what to do anymore…. there are different ways of doing this and I would really try to pick the right one. If this would be the best option, I would really appreciate a small sample code of how I would integrate polymorphism and inheritance in
relation to my program sample above… I know I am asking for alot….but sincerely, I have to plead ignorance here…. I wouldn’t know where to start with all of this!  

I thank all who read this post till the end…. and I appologize for its lenght and its oversimplistic contents. In any case I hope I can get through this new programming hurdle once again.

Best regards

Robert

Hi Roberto,We’re doing research on this issue. It might take some time before we get back to you.In addition, the following link tells about how create a pointer to struct:http://stackoverflow.com/questions/1580070/in-c-how-to-set-a-pointer-to-a-structure-member-that-is-an-arrayhttp://social.msdn.microsoft.com/Forums/en-US/clr/thread/7dbd5ef6-c3a5-4787-84e0-758769671450http://stackoverflow.com/questions/863952/passing-structures-as-arguments-while-using-pthread-create Thank you for your understanding,

Hi,Your question falls into the paid support category which requires a more in-depth level of support.  Please visit the below link to see the various paid support options that are available to better meet your needs.http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophoneThanks!

I’m not sure why you think your structure needs to contain pointers to other structures.  Why not just include them inside of the main struct?  No need to malloc 15 of them.Like you said, just allocate your structure in the WM_CREATE and free it in the WM_DESTROY.  You can assign it to GWLP_USERDATA or extra window bytes to store it along with your window, then just free it when you are done.