NO

Author Topic: GetOpenFileName problem with double click  (Read 11106 times)

PhilG57

  • Guest
Re: GetOpenFileName problem with double click
« Reply #15 on: January 02, 2015, 04:21:12 PM »
Thank you all for the testing; I now have to believe one of my file explorer extensions is causing the problem.  One of these days, I'll remove and test each one to find the culprit.

Another question and favor to ask: when you are testing my application, I assume you are doing so using Pelles IDE.  (To remind you, the problem does not occur if running the program with Project->Execute.)  When I run the program in debug mode, the global variable "gstDBhdr" does not show up in the list of globals.  "gstDBhdr" is defined in database.c and extern'ed to a couple of other modules.  I know the variable is actually in the program because I can follow the programs testing of values read into "gstDBhdr".  But I can't see the !@#$# thing.

Does this problem appear on your systems???

Thanks again. 

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: GetOpenFileName problem with double click
« Reply #16 on: January 03, 2015, 04:00:51 AM »
Thank you all for the testing; I now have to believe one of my file explorer extensions is causing the problem.  One of these days, I'll remove and test each one to find the culprit.

Another question and favor to ask: when you are testing my application, I assume you are doing so using Pelles IDE.  (To remind you, the problem does not occur if running the program with Project->Execute.)  When I run the program in debug mode, the global variable "gstDBhdr" does not show up in the list of globals.  "gstDBhdr" is defined in database.c and extern'ed to a couple of other modules.  I know the variable is actually in the program because I can follow the programs testing of values read into "gstDBhdr".  But I can't see the !@#$# thing.
That smells awfully like an uninitialized variable... :-\

Ralf

PhilG57

  • Guest
Re: GetOpenFileName problem with double click
« Reply #17 on: January 03, 2015, 02:53:15 PM »
'Morning.  Well, it's a structure and a global one at that.  Initialized or not, I should at least be able to see it during debug.  And, once again, even though I cannot display the global variable, I know it is being 'seen' and used correctly during program execution.

I know I have a ton of globals as they make early development easier; some of these globals will eventually be converted to locals as I add functionality and improve the code. 

What I'd like to know if anyone else is, or is not, able to see this global under debug so I'll know if my problem is another "feature" on my system.  Thanks.

czerny

  • Guest
Re: GetOpenFileName problem with double click
« Reply #18 on: January 03, 2015, 05:58:45 PM »
It is neither seen initialized nor not initialized. It could not selected in the watch tab too. Pelles C 7RC4.

PhilG57

  • Guest
Re: GetOpenFileName problem with double click
« Reply #19 on: January 04, 2015, 03:17:10 PM »
You are absolutely right!  If I update the structure definition by adding an initialization value to it such as "gstDBhdr = {0]", then I can see the structure during debug.  Or, if I explicitely initialize a structure member such as "gstDBhdr.id = '' ';" somewhere in the program, then I can see the structure under debug as well.

What was/is confusing is that the structure gstDBhdr is initialized using ZeroMemory and is read into using ReadFile so I thought those references should suffice.  Maybe because both of those statements use an "&" in front of the structure name --ZeroMemory(&gstDBhdr, 0 , sizeof(gstDBhdr))--, the compiler didn't pick up the reference.

Anyway many thanks.  I'm a happy camper again.  Case closed.  Thanks again.

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2096
Re: GetOpenFileName problem with double click
« Reply #20 on: January 04, 2015, 08:27:51 PM »
I'm not sure, but I think that the problem i related to *where* the variable is declared.
Uninitialized vars are by default in the BSS section, that is not present in the executable PE, but is dynamically created at loading.
Maybe PellesC still miss code to link the variable addresses against the BSS creation.
It is better to be hated for what you are than to be loved for what you are not. - Andre Gide

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: GetOpenFileName problem with double click
« Reply #21 on: January 05, 2015, 04:00:51 AM »
You are absolutely right!  If I update the structure definition by adding an initialization value to it such as "gstDBhdr = {0]", then I can see the structure during debug.  Or, if I explicitely initialize a structure member such as "gstDBhdr.id = '' ';" somewhere in the program, then I can see the structure under debug as well.
That's what I meant. This is a typical symptom when a program behaves differently between running in an IDE/debugger or standalone. When using a debugger, usually all memory space is cleared before execution, to get a "clean slate" on each debugger run. When running a program standalone, the memory area for is in a lot of cases undefined, though static global variables "should" be zeroed before program start. I have made it a good habit in +30 years of programming to never depend on such compiler behavior and always initialize all variables to a known state...

Ralf

PhilG57

  • Guest
Re: GetOpenFileName problem with double click
« Reply #22 on: January 05, 2015, 03:40:13 PM »
Yes, I too like to initialize variables even though they should have been done so by the compiler.  That's why I did the ZeroMemory thing on my global structure.

But I have to admit I thought all globals would be visible under debug regardless of whether or not they had been explicitely initialized.  I now understand I have to explicitely reference the variable (or structure member) and the "&" on ZeroMemory does not cut it.

I also have to admit I don't understand the difference, if any, between global and static global variables.  Both exist for the life of the program, and both should be visible to all compilation units that have an extern for the variable.

Thanks again.