Pelles C forum

Pelles C => Announcements => Topic started by: Pelle on May 02, 2009, 12:12:08 PM

Title: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 12:12:08 PM
Pelles C version 6.0, Release Candidate #1, is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm

The German translation will be added later.

Pelle
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Romashka on May 02, 2009, 01:51:12 PM
Many thanks!

BTW, I've noticed that there is no more 'Include files' subtree in filelist.
Is it a bug or an intended change?
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 02, 2009, 02:04:31 PM
Thanks Pelle.

I have "Invalid jump into 'VLA' block." error - as far as I can see nothing jumps into a VLA block. The error occurs on a goto line.

I use a few goto statements to label cleanup;

Here is the cleanup part

  cleanup:
   // release interfaces
   if (pIDragSourceHelper)
      pIDragSourceHelper->lpVtbl->Release(pIDragSourceHelper);
   if (pIDataObject)
      pIDataObject->lpVtbl->Release(pIDataObject);
   if (pIDropSource)
      pIDropSource->lpVtbl->Release(pIDropSource);
   if (pIDropTarget)
      pIDropTarget->lpVtbl->Release(pIDropTarget);

   RevokeDragDrop(hwndMain);
   if(hbm){
      DeleteObject(hbm);
   }
   if(pp[0]){
      free(pp[0]);
   }
   return ret;

EDIT: That's in the 32 bit version.

John





Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 02:33:05 PM
Romashka: I now filter out include files located outside the (top-level) project (directory). I had a number of projects where I found it very confusing to see irrelevant include files in the project tree (not my own files).

John: a "VLA block" should never be created unless there actually is variable-length array somewhere. Are you, for example, setting the size of an array using a "const int ..." variable, or similar. In C this *will* create a VLA, unlike C++ and some other buggy C compilers...

If not: is it possible to make a smaller, compilable, example?
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Romashka on May 02, 2009, 02:46:22 PM
I now filter out include files located outside the (top-level) project (directory). I had a number of projects where I found it very confusing to see irrelevant include files in the project tree (not my own files).
Aha, the problem is that my sources are in a sibling tree of a project directory, not a child tree.
Since they are referred as ..\sources\*.{c,h} in .ppj files - shouldn't IDE know that it should display all header files listed in .ppj?
Title: Re: Version 6.0, Release Candidate #1 available
Post by: ssb on May 02, 2009, 03:13:40 PM
Just a few UI issues I've noticed so far.

1. Resizable dialog size (IDE) not saved.
2. Installer not using system default dialog font. Quite minor issue, but MS Sans Serif looks really crappy under Vista.
3. Same as #2 but in dialogs of process viewer and registry editor applets (about, find, view from timestamp, etc.).
4. Still no "delete active line" editor command. :) Dear Pelle, could you please consider implementing this old suggestion (http://forum.pellesc.de/index.php?topic=1340.0) in v6 final?

Thank you for the v6. Really appreciated your efforts!
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 03:43:31 PM
1) By design.
2) MS Sans Serif looks pretty everywhere, the Vista font looks ugly everywhere.
3) See 2)
4) See 1)
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 02, 2009, 03:48:42 PM
Pelle,

Here is a small fragment that shows my problem.

As you can see the code does have a VLA but there never used to be a problem.

Code: [Select]
int Drop(void)
{
int ret = 0;

int nItems = 10;
if (!nItems){
goto cleanup;
}

int indexs[nItems];

  cleanup:

return ret;
}

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: ssb on May 02, 2009, 04:17:17 PM
1) By design.
2) MS Sans Serif looks pretty everywhere, the Vista font looks ugly everywhere.
3) See 2)
4) See 1)

1. Hmm, I assume I can live with it.
2. I'd agreed if Vista wasn't the current OS version. A simple OS detect - font substitution function could do the job. After all, the standard alternative dialog font (Tahoma) looks pretty everywhere, incuding Vista and Win7.
3. Same as #2.
4. With all respect, is it so hard to implement such a simple functionality? Certainly you are who decide what's useful or not, but do you really know many code editors without a "delete-line" command?

Thanks!
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 05:00:46 PM
John,

Yes, it used to work - except maybe for a brief period in some beta, a few versions back, when I tried to add this check the last time.

At least in your example it's possible to put the array in a new block (scope):
Code: [Select]
    /* new block */
    {
        int indexs[nItems];
        ...
    }

My copy of the C99 standard contains the following example, which may be open to some interpretation:

EXAMPLE 2 A goto statement is not allowed to jump past any declarations of objects with variably
modified types. A jump within the scope, however, is permitted.


Code: [Select]
goto lab3; // invalid: going INTO scope of VLA.
{
double a[n];
a[j] = 4.4;
lab3:
a[j] = 3.3;
goto lab4; // valid: going WITHIN scope of VLA.
a[j] = 5.5;
lab4:
a[j] = 6.6;
}
goto lab4; // invalid: going INTO scope of VLA.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 02, 2009, 05:14:54 PM
Pelle,

======================
My copy of the C99 standard contains the following example, which may be open to some interpretation:

EXAMPLE 2 A goto statement is not allowed to jump past any declarations of objects with variably
modified types. A jump within the scope, however, is permitted.
======================

Ok I see where you are coming from but surely the VLA in my example is in scope until the end of the function. My label cleanup is therefor in scope. No?

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 05:31:45 PM
Ok I see where you are coming from but surely the VLA in my example is in scope until the end of the function. My label cleanup is therefor in scope. No?
Yes, but you are also jumping *around* the declaration: int indexs[nItems]; -- but I assume to a point in the code where the array isn't used anymore. The compiler isn't cleaver enough to track variable "liveness" at this point in the process (where the warning is issued), it only looks at blocks (scopes).

I guess the general idea is that "int indexs[nItems];" will generate some form of machine code with any compiler (to allocate the array), and the source code shouldn't be able to jump past that point to a place where it uses the (uninitialized) array.

EDIT: At least one Intel compiler seems to agree with me:
test.c(7): error: transfer of control bypasses initialization of:
            variable length array "indexs" (declared at line 10)
          goto cleanup;
          ^
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 05:37:04 PM
snip
2. Since M$ apparently can't be bothered making a better upgrade path for dialog fonts and new visual styles, I'm certainly not going to do the job for them. I will continue to use "MS Shell Dlg" for now.
4. I don't like it, I won't add it. This has now been explained to you many times. Nagging about it some more isn't going to help you. Good bye.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 02, 2009, 06:27:08 PM
Pelle,

Ok, I'll find a way around it. Thanks.

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: jwzumwalt on May 02, 2009, 07:09:38 PM
Pelle,

I wanted to thank you and the rest of the group for the mature communication that takes place regarding PelleC. I noticed in another post you placed a goal of not having a "jillion" option interface. I agree. Of course everyone likes there particular idiosyncrasies to be catered to... (I would like the cursor to go past the end of the line!). But the last couple of conversations that others have had struck me as unusually civil for strangers with differing views on the internet.

I think it speaks quite well of the users and your development cycle that others are excepting the devotion that a volunteer project requires in time and resources. Keep up the good work!
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Romashka on May 02, 2009, 07:22:17 PM
When I compile any application (even 'Hello world!') with DLL runtime I get a message that entry point to _except_handler3 cannot be found in pocrt.dll  :o
Any ideas why?
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 07:40:01 PM
JohnF: OK. Sorry if this caused you trouble, but I belive the current behavior is/should be more correct.

jwzumwalt: Thanks. Yes, it's generally a very nice group. I will try to continue this project as long as I can (or as long as there appear to be some interest in it)...

Romashka: No idea, really. I just tried a small test-program with structured exception handling and the C runtime DLL, and that worked. Do you have any more information? X86 build, I guess? Any special compiler options, linker libraries, etc?
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Romashka on May 02, 2009, 07:52:36 PM
No idea, really. I just tried a small test-program with structured exception handling and the C runtime DLL, and that worked. Do you have any more information? X86 build, I guess? Any special compiler options, linker libraries, etc?

Yes, 32bit x86. Console app (win32 apps have same issue).
Code: [Select]
int main(void) { return 0; }
from .ppj:
Code: [Select]
CCFLAGS =  -Tx86-coff -MD -Ot -Ob1 -fp:precise -W1 -Gd #
ASFLAGS =  -AIA32 -Gd #
LINKFLAGS =  -subsystem:console -machine:x86 -release  kernel32.lib advapi32.lib delayimp.lib#
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 02, 2009, 08:11:26 PM
Yes, 32bit x86. Console app (win32 apps have same issue).
Hmm... I created a new console project, pasted the code (just in case), and also the compiler and linker options ("Macros" tab). When I build the project, it works fine here.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 02, 2009, 09:31:38 PM
Pelle,

===========
JohnF: OK. Sorry if this caused you trouble, but I belive the current behavior is/should be more correct.
===========

No problem really, easily sorted. Thanks for the new version.

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: dancho on May 03, 2009, 10:48:00 AM
heya Pelle,
thx for the new release ...

It seems that I found 5 lines of code that crashes Pelles C,let me explain my steps:
1.File->New->Project->Win32Console Program->Create
2.File->New->Source Code
3.Save&Add to Project as main.c
4.code:
Code: [Select]
#include <stdio.h>
int main()
{
int c='d';
printf(":%c:\n",c);

return 0;
}
5.compile,link,run and for the first time everything work fine,but
6.when I try to change something in code or close Ide ( or everything else really ) this message box appear
7."error writting to file 'main.c"
  "The Process cannot access the file because it is being used by another process."
8. :)
9.btw Avira is finding this in the download link "DR/Zlob.Gen",false alaram I hope  ;)


Title: Re: Version 6.0, Release Candidate #1 available
Post by: Robert on May 04, 2009, 07:52:47 AM
Using Pelles C X64 version 6.0, Release Candidate #1

This line

printf("%s% d%s% d%s","[lines In:",(int)LinesRead,"] [lines Out:",(int)gLinesWritten,"] ");

produces this warning

warning #2234:
Argument 3 to 'printf' does not match the format string;
expected 'char *' but found 'int'.

This line

printf("%s% d%s% .7G%s\n","[Statements:",(int)Statements,"] [Time:",(float)Elapsed," sec's]");

warning #2234:
Argument 3 to 'printf' does not match the format string;
expected 'char *' but found 'int'.

Robert Wishlaw
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 04, 2009, 08:45:24 AM
Try it like this.

Code: [Select]
int gLinesWritten, LinesRead, Statements;
float Elapsed;

printf("%s %d %s %d %s","[lines In:",(int)LinesRead,"] [lines Out:",
(int)gLinesWritten,"] ");


printf("%s %d %s %.7G %s\n","[Statements:",(int)Statements,"] [Time:",
(float)Elapsed," sec's]");

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 04, 2009, 08:53:47 PM
It seems that I found 5 lines of code that crashes Pelles C,let me explain my steps:
I suspect your definition of "crash" is rather different from mine.

The problem is with "browse information" and the ' character; most C programmers would probably write int c='d'; with spaces, to make it more readable: int c = 'd';
If you make this change it will work for now (until the bug is fixed).

I'm pretty sure I've never heard of Avira, are you sure it's working?!
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Robert on May 04, 2009, 10:17:18 PM
Try it like this.

Code: [Select]
int gLinesWritten, LinesRead, Statements;
float Elapsed;

printf("%s %d %s %d %s","[lines In:",(int)LinesRead,"] [lines Out:",
(int)gLinesWritten,"] ");


printf("%s %d %s %.7G %s\n","[Statements:",(int)Statements,"] [Time:",
(float)Elapsed," sec's]");

John


Hi John:

I suspect that, because of my poor example, you are missing my point. Here's a pair of better examples.


This code

Code: [Select]

#include <stdio.h>

int main(int argc, char *argv[])
{
  printf("%s% d%s% d%s\n","Negative: ",-12345," Check alignment?  ",67890," Yes");
  printf("%s% d%s% d%s\n","Positive: ", 12345," Correctly aligned?",67890," Yes");
  return 0;
}


correctly formats the output so that it is properly aligned

Code: [Select]

Negative: -12345 Check alignment?   67890 Yes
Positive:  12345 Correctly aligned? 67890 Yes



but an improper warning is issued, that is,

snip.c(5): warning #2234:
Argument 3 to 'printf' does not match the format string;
expected 'char *' but found 'int'.

snip.c(6): warning #2234:
Argument 3 to 'printf' does not match the format string;
expected 'char *' but found 'int'.

 
This code, adapted from your suggested solution to the problem, does not issue a warning

Code: [Select]

#include <stdio.h>

int main(int argc, char *argv[])
{
  printf("%s %d %s %d %s\n","Negative: ",-12345," Check alignment?  ",67890," Yes");
  printf("%s %d %s %d %s\n","Positive: ", 12345," Correctly aligned?",67890," No");
  return 0;
}


however, it does not format for the desired alignment.

Code: [Select]

Negative:  -12345  Check alignment?   67890  Yes
Positive:  12345  Correctly aligned? 67890  No


I hope that I have made my point understandable.

Robert Wishlaw
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 04, 2009, 10:55:22 PM
You will have to rethink your alignment method.

The point is the character after % is the control, in various places you have a space directly after the %, this will not do.

EDIT:

For example

%s% d - no good

% s % d - no good

%s %d - good

%s%d - good

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Robert on May 05, 2009, 12:23:20 AM
You will have to rethink your alignment method.

The point is the character after % is the control, in various places you have a space directly after the %, this will not do.

EDIT:

For example

%s% d - no good

% s % d - no good

%s %d - good

%s%d - good

John


John, the space following the % is a flag described in the flag characters and their meanings description on the fprintf function page of the Pelle's C Help file.

The Pelle's C Help file states that when a space follows the %, "If the first character of a signed conversion is not a sign, or if a signed conversion results in no characters, a space is prefixed to the result. If the space and + flags both appear, the space flag is ignored."

Robert Wishlaw


Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 05, 2009, 08:23:43 AM
I didn't know about that.

However, the normal way of alignment is to use spaces and tabs to achieve what you want

%s     \t      %d

Obviously if it is a bug Pelle should look at it.

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Christian on May 05, 2009, 09:51:07 AM
@Pelle & dancho:

I am a user of Avira Professional and I had no alerts.

@ Pelle: Avira is an antivirus solution which is prosperous in Germany. www.avira.com (http://www.avira.com)
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 05, 2009, 04:53:39 PM
@Robert: OK, I see your point now. Yes, it's a bug - the compiler is currently looking for +, -, #, 0 - but I forgot the space (which I apparently never use myself). This will be fixed; either in RC2 or the official release, depeneding on other bug reports...

@Christian: OK, thanks for the info. ( I subscribe to another, usually top-ranking, antivirus solution, so viruses should not be an issue; let's leave it at that... )
Title: Re: Version 6.0, Release Candidate #1 available
Post by: AlexN on May 06, 2009, 09:45:26 AM
Pelles C version 6.0, Release Candidate #1, is now available for download:

Many thanks, it is again a great piece of software.

I have some comments to it:

1.) The code of the new compiler seems to be faster.

2.) If the format of the project file is changed in a way, that the previos version of poide is not able to load it, it would fine when a backup of the project file would be made. (OK, it is possible to change the line "POC_PROJECT_VERSION = 6.00#" to "POC_PROJECT_VERSION = 5.00#" to load it again, but a backup would be fine)

3.) I have a program where i get the message that ___ftoll is not a member of pocrt.dll, when i compile with the Runtime library option "Multithreaded (DLL)". All other options work there. I looked at pocrt.dll at the old and new version. The version number is the same but the newer it is little bit larger and at the exports there is a difference at some labels (like __ftoll).
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Romashka on May 06, 2009, 12:04:29 PM
Yes, 32bit x86. Console app (win32 apps have same issue).
Hmm... I created a new console project, pasted the code (just in case), and also the compiler and linker options ("Macros" tab). When I build the project, it works fine here.

I've tried on a different PC - created a helloworld program using the console app wizard, the only modified setting was 'Runtime library - Multithreaded (DLL)' - and got the same error.
Both PCs have Windows XP SP3 Russian installed, programs were compiled using 6.00 32-bit.


EDIT: here's the text in Debug tab (the application was compiled without any debug info though):
Code: [Select]
Process C5C started
Thread F9C started
Loading untitled at 00400000
Loading ntdll.dll at 7C900000
Loading C:\WINDOWS\system32\kernel32.dll at 7C800000
Loading C:\Program Files\PellesC\Bin\pocrt.dll at 77000000
Exception: C0000139
Thread C4 started
Thread C4 ended with C000013A
Thread F9C ended with 0
Process C5C ended with C000013A
Done
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 06, 2009, 05:15:50 PM
Many thanks, it is again a great piece of software.
Thanks.

1.) The code of the new compiler seems to be faster.
The new register allocator and optimizer should do some good - for programs compiled with the new compiler, and for the compiler itself (since it's compiled with the new compiler). The whole "middle-end" of the compiler is rewritten, using new alogorithms (it does more than before, but possibly faster).

2.) If the format of the project file is changed in a way, that the previos version of poide is not able to load it, it would fine when a backup of the project file would be made. (OK, it is possible to change the line "POC_PROJECT_VERSION = 6.00#" to "POC_PROJECT_VERSION = 5.00#" to load it again, but a backup would be fine)
The only time I can see this being minimally useful is during the test period for a new release. I'm pretty sure I don't want my disk filled with backup copies of project files, generally speaking. This would mean making backups only for release candidates, which doesn't sound right to me...

3.) I have a program where i get the message that ___ftoll is not a member of pocrt.dll, when i compile with the Runtime library option "Multithreaded (DLL)". All other options work there. I looked at pocrt.dll at the old and new version. The version number is the same but the newer it is little bit larger and at the exports there is a difference at some labels (like __ftoll).
The version number 5.0 for pocrt.dll and pocrt64.dll is wrong, it should be 6.0. This is a bug.
The decoration for exported symbols has changed a bit, to try and match Microsoft better. Because of this you can get linking errors if not all modules are recompiled.
If you get runtime errors, it sounds like the wrong version of pocrt.dll is being picked up somehow.
What happens if you load pocrt.dll into the IDE, change the version resource to 6.0, and save it? I guess "FILEVERSION", and maybe "PRODUCTVERSION", should be the important ones.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Romashka on May 07, 2009, 09:33:24 AM
The version number 5.0 for pocrt.dll and pocrt64.dll is wrong, it should be 6.0. This is a bug.
Aha, this may explain my bug too.
A fresh install of 32-bit Pelles C 6.00 RC1 (on a system where it wasn't ever installed, so no old version could exist) has pocrt.dll with file version 5.00.3 while other DLLs like pobr.dll and porc.dll have 6.00.0.
So it looks that RC1 is incorrectly packaged.
The reason you could not reproduce my bug on your system is that you obviously have pocrt.dll v6.00.0 on your system.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Robert on May 07, 2009, 11:26:17 AM
The version number 5.0 for pocrt.dll and pocrt64.dll is wrong, it should be 6.0. This is a bug.
Aha, this may explain my bug too.
A fresh install of 32-bit Pelles C 6.00 RC1 (on a system where it wasn't ever installed, so no old version could exist) has pocrt.dll with file version 5.00.3 while other DLLs like pobr.dll and porc.dll have 6.00.0.
So it looks that RC1 is incorrectly packaged.
The reason you could not reproduce my bug on your system is that you obviously have pocrt.dll v6.00.0 on your system.

Pelle's C Version 6.0 RC1 64-bit
pocrt64.dll file version is 5.03.0, product version 5.00 according to the Properties Details.

Robert Wishlaw
Title: Re: Version 6.0, Release Candidate #1 available
Post by: AlexN on May 07, 2009, 03:37:43 PM

2.) If the format of the project file is changed in a way, that the previos version of poide is not able to load it, it would fine when a backup of the project file would be made. (OK, it is possible to change the line "POC_PROJECT_VERSION = 6.00#" to "POC_PROJECT_VERSION = 5.00#" to load it again, but a backup would be fine)
The only time I can see this being minimally useful is during the test period for a new release. I'm pretty sure I don't want my disk filled with backup copies of project files, generally speaking. This would mean making backups only for release candidates, which doesn't sound right to me...
I think it is only necessary pre-release versions. Perhaps you create for this a link for the new version with the parameters /n and /xml so that you don't overwrite the options from a stable version with the parameters for a pre-release version.

3.) I have a program where i get the message that ___ftoll is not a member of pocrt.dll, when i compile with the Runtime library option "Multithreaded (DLL)". All other options work there. I looked at pocrt.dll at the old and new version. The version number is the same but the newer it is little bit larger and at the exports there is a difference at some labels (like __ftoll).
The version number 5.0 for pocrt.dll and pocrt64.dll is wrong, it should be 6.0. This is a bug.
The decoration for exported symbols has changed a bit, to try and match Microsoft better. Because of this you can get linking errors if not all modules are recompiled.
If you get runtime errors, it sounds like the wrong version of pocrt.dll is being picked up somehow.
What happens if you load pocrt.dll into the IDE, change the version resource to 6.0, and save it? I guess "FILEVERSION", and maybe "PRODUCTVERSION", should be the important ones.

To change the version number of the file pocrt.dll has no effect. When I start the program from the IDE I can see that the correct DLL is loaded. I think that I have this problem with all GUI-programs and the Runtime library option "Multithreaded (DLL)".
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 10, 2009, 12:00:22 PM
I modified the module-definition file for pocrt.dll to match the new export handling, and the exported symbols now look like version 5.0; the version was bumped to 6.0 - this will be in RC2.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: virtualcoder128 on May 11, 2009, 06:46:48 AM
I want to thank to pelle for this wonderful tool saved my life/work(Im tired of VS)  ;D And congratz for this release and I will try my best to help support Pelles C, It is Awesome.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: DaLiV on May 13, 2009, 01:51:16 PM
V6
width,height measured in "dialog units", can that be switched to pixels (or in configuration set measure of 1 dialog unit to pixel) ?
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 14, 2009, 04:07:54 PM
width,height measured in "dialog units", can that be switched to pixels (or in configuration set measure of 1 dialog unit to pixel) ?
No, since pixels would be pretty useless...
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 16, 2009, 11:20:43 AM
Pelle, in your changes file you say that the source code is included for resizable dialogs.

"Added static library, including source code, for basic handling of resizable dialogs."

Where is the source code?

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 16, 2009, 03:06:48 PM
Pelle, in your changes file you say that the source code is included for resizable dialogs.

"Added static library, including source code, for basic handling of resizable dialogs."

Where is the source code?
The source code is installed in the default project folder, under the name Resizer - "<Windows-documents>\Pelles C Projects\Resizer". The actual name for <Windows-documents> depends on the Windows version.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 16, 2009, 03:41:08 PM
It's not anywhere on my hard drive. I don't have a folded called 'Windows-documents'.

EDIT: I've found

"My Documents\Pelles C Projects\"

But no Resizer.

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Stefan Pendl on May 16, 2009, 04:29:08 PM
I don't have a folded called 'Windows-documents'.
Check My Documents, I think this is what Pelle is referring to.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 16, 2009, 04:34:29 PM
Yes - it's "Dokument" on my Swedish Vista version (physical folder "C:\Users\Pelle\Documents"), but I guess "My documents" is what you are looking for...
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 16, 2009, 04:41:25 PM
Got it thanks after re-installing PellesC.

What happened is I over-wrote my C drive with a backup the other day - so getting rid of anything new - didn't know there was any PellesC stuff on that drive.

Anyway, thanks.

John
Title: Re: Version 6.0, Release Candidate #1 available
Post by: JohnF on May 18, 2009, 03:14:28 PM
Pelle,

The 'Resizer' library looks good, I'm sure quite a few people will find it handy.

Thanks for adding it to your distribution.

John




Title: Re: Version 6.0, Release Candidate #1 available
Post by: Pelle on May 18, 2009, 03:37:21 PM
OK - thanks, John.
Title: Re: Version 6.0, Release Candidate #1 available
Post by: DaLiV on May 19, 2009, 12:12:02 PM
width,height measured in "dialog units", can that be switched to pixels (or in configuration set measure of 1 dialog unit to pixel) ?
No, since pixels would be pretty useless...
on big pc may be, but on limited size screens of PocketDevices interface must be done in pixels ... otherwise it's unusable ... 320x240, no panning, no moving ...
Title: Re: Version 6.0, Release Candidate #1 available
Post by: Robert on May 19, 2009, 10:33:11 PM
width,height measured in "dialog units", can that be switched to pixels (or in configuration set measure of 1 dialog unit to pixel) ?
No, since pixels would be pretty useless...
on big pc may be, but on limited size screens of PocketDevices interface must be done in pixels ... otherwise it's unusable ... 320x240, no panning, no moving ...

To begin to understand what is involved please have a look at "Design dialogs in pixels not in dialog units"
on the Pocket PC Developer Network Forum at

http://www.pocketpcdn.com/forum/viewtopic.php?t=1715&view=previous&sid=ac392b9c004b40c9659dc869944746c6

Robert Wishlaw