Recent posts

#71

Beginner questions / Re: Working Directory woes

Last post by John Z - July 03, 2026, 11:20:02 PM

Hi PhilG57,

Have you tried setting the ofn.lpstrFile parameter to the path you want to start in?
I do this, it seems to work.  Documentation says this will be used as the initial directory when the dialog starts, unless the value is NULL.  Also may need to set lpstrInitialDir to NULL, but I don't recall doing that - ?

Code Select Expand

The file name used to initialize the File Name edit control.
The first character of this buffer must be NULL if initialization
is not necessary. When the GetOpenFileName or GetSaveFileName
function returns successfully, this buffer contains the drive
designator, path, file name, and extension of the selected file.

Code Select Expand

Windows 7:

    If lpstrInitialDir has the same value as was passed the
first time the application used an Open or Save As dialog box,
the path most recently selected by the user is used as the
initial directory.

    Otherwise, if lpstrFile contains a path, that path is
the initial directory.

Code Select Expand

Windows 2000/XP/Vista:

    If lpstrFile contains a path, that path is the initial directory.
    Otherwise, lpstrInitialDir specifies the initial directory.
https://learn.microsoft.com/en-us/windows/win32/api/commdlg/ns-commdlg-openfilenamea


John Z

#72

Beginner questions / Re: Working Directory woes

Last post by PhilG57 - July 03, 2026, 04:31:40 AM

Stack Overflow says the directory last selected by GetOpenFileName is stored in the registry and used the next time GetOpenFileName is called.  This seems to be the case, even though I make a point to reset the working directory to that obtained earlier in my code.  As also suggested there, I added the flag "OFN_NOCHANGEDIR" to the GetOpenFileName call with no change in behavior.

I do think this is a user caused error but have yet to determine where I went wrong.

#73

Beginner questions / Re: Importing a function from ...

Last post by Vortex - July 02, 2026, 08:12:59 PM

Hi jm,

Windows 64-bit supports only the fastcall calling convention.

#74

Beginner questions / Working Directory woes

Last post by PhilG57 - July 02, 2026, 04:16:44 PM

I have a Windows project with multiple versions kept in separate directories.  I edit and update in one directory and when those changes look and test good, I move them to another, separate, directory of more stable code.

In any of those project versions, when I open a file with GetOpenFileName(), the directory shown from which to select a file to open, is the directory last used by Pelles C.  For example, in the GetOpenFileName() dialog, if I change to a different directory and select a file from there, that directory becomes the 'default' location shown by GetOpenFileName() the next time it is called.

So far, so good I think.  What I don't understand is with the opening of a new or different project using the same instance of Pelles C, or especially with a new clean instance of Pelles C, why does the default GetOpenFileName() use what I selected before and not the default directory listed in my project's options. As part of the initialization code, I do execute a GetCurrentDirectory() followed by a SetCurrentDirectory() to no avail.

As always, thanks in advance.

#75

Announcements / CMake 4.4.0 Supports Pelles C

Last post by Robert - July 01, 2026, 04:08:26 AM

CMake 4.4.0 Supports Pelles C.

https://gitlab.kitware.com/cmake/cmake/-/work_items/21536

DownLoad here:

https://cmake.org/download/

#76

Beginner questions / Re: Importing a function from ...

Last post by jm - June 30, 2026, 05:27:04 PM

Just Enable Microsoft extensions to remove warning

Good to know that, thanks for your help.  The F1 help is great too, for anyone else new to Pelles C.

#77

Beginner questions / Re: Importing a function from ...

Last post by TimoVJL - June 30, 2026, 12:51:55 PM

...\MyDLL\pelles\pelles.c(3): warning #2203: Function 'my_function' can't be __stdcall, changed to __cdecl.

Just Enable Microsoft extensions to remove warning

#78

Beginner questions / Re: Importing a function from ...

Last post by jm - June 28, 2026, 03:35:40 PM

It's all fixed, thank you very much for your help.  I realise my ridiculous mistake now — while I can put the .LIB in a separate library folder as you pointed out, the .DLL at least has to be in the path when the executable runs.

Incidentally, the float return was also my error, it wasn't a problem at all in the end.  My DLL is in fact 64-bit code, but if I change the calling convention to float __stdcall, it warns me :

...\MyDLL\pelles\pelles.c(3): warning #2203: Function 'my_function' can't be __stdcall, changed to __cdecl.

Interesting to see that.

#79

Beginner questions / Re: Importing a function from ...

Last post by TimoVJL - June 28, 2026, 12:39:51 PM

For libraries, use Project options -> General -> Folders -> Libraries

If a your JDL.DLL exports function, a calling convention had to know at least in x86, as x64 have only one calling convention.
like:

Code Select Expand

float __cdecl myfunc(float);  // _myfuncor

Code Select Expand

float __stdcall myfunc(float); // _myfunc@4

#80

Beginner questions / Re: Importing a function from ...

Last post by jm - June 28, 2026, 11:54:29 AM

Many thanks indeed Vortex, that worked very well.  As I'd expected, it was necessary for me to put my .DLL and .LIB into the project's folder and also go to Project — Project options — Linker, then add the .LIB filename to the Library and Object Files box.

Is there a way to inform the compiler/linker that the .DLL and .LIB files are in a specific path outside the project folder?  I tried specifying the full path of the .LIB but it wouldn't compile, presumbly because it also requires the path to the .DLL.  I couldn't find a way of doing that.

I wasn't able to return a float or double with the expected value, but I expect that's due to calling methods, so I need to experiment further with that.