I am updating old programs. But I've got a little problem. Not all files are displayed in the left panel.
In the programs I have worked in in recent years, those files are not displayed in older programs. I compared between the ones that work and the ones that don't but can't find any difference. Is there a setting or something else that needs to be done in Pelles-C for them to be included?
The picture I attached shows what I mean (it is the latest test of code from a forum member where it works).
try to remove .tag file if it helps
OK!
I will try it!
I think TimoVJL is right - it should 'fix' it.
To remove/delete/or rename the .tag file first close the project then
navigate to the project directory and delete it or rename it. The .tag
file will be recreated when you next open the project.
Since the .tag file is actually a SQL db file the format may have changed.
You can also view the .tag file with a SQL Lite browser -
From time to time I've had the opposite issue - the panel will show doubled
entries. That is one or more procedure show in two lines of the tree view.
So I delete the .tag and everything recovers.
John Z
No, that didn't help.
Put all files in another folder except the .c and .rc files and created new project.
Didn't help!
(Gets a lot of new errors too)
Hi Alderman2,
Another possibility is they are not being recognized as valid C files.
Tedious, but you might need to open each one in a text editor, Or even Pelles IDE
and make sure that there is at least a one new line after the last code statement
in the file.
You might try it on just one file first to see if it helps.
John Z
The function that is not included in the list, which I have circled in red in the image, is an internal function in the main c file.
I get all such files in several of the projects but not all. (I got rid of all the new warnings now. I added some in "Project Options", including "WIN32_DEFAULT_LIBS".)
Several years ago I had the same problem. Then I emailed Pelle and sent him a project so he could see what was wrong. He answered what I should do but I no longer remember the answer. After I did as he said it worked perfectly.
My hiatus from programming has left me rusty. Don't remember everything.
I remember solving the problem before by making a template of a project like this work. Since then I have always used that template. The same template I posted in the other thread to test the error with Win 24H2.
I did this:
- Copied the template to the folder the new project is to be built in.
- Renamed all files to the new name.
- Opened the .prj file and renamed it from "Template" to the new name.
- Opened the .RC file and renamed it to the new name.
- Created an icon with the new name.
- Tested if it worked and sometimes fixed some errors or warnings.
- Started writing my code.
So I have been working with several of my projects for several years to get everything in that list we talk about. Has worked perfectly. If I create a new project through Pelles-C it becomes complicated, for example the project ends up in the wrong folder. Have to work a bit to end up in the right folder. Then I had to change settings and add .libs, WIN32_DEFAULT_LIBS and some other things. Also, I didn't always get features in that list like in the picture I showed. Med mallen fungerar det alltid perfekt. So, the question is what differentiates the template from creating a new project?
Well I only use the default wizards which I guess you are calling templates?
I do know that the default ones are DLLs. Also know that DLL for Pelles Add-ins
need to be rebuilt, most of the time, when a new version of Pelles issues.
Maybe not helpful - but its all I have....
John Z
Pelles C have project Wizard interface
Experimental New Workspace Add-In (https://forum.pellesc.de/index.php?topic=4603.msg29141#msg29141)
Quote from: John Z on December 12, 2024, 05:39:36 PM
Well I only use the default wizards which I guess you are calling templates?
I do know that the default ones are DLLs. Also know that DLL for Pelles Add-ins
need to be rebuilt, most of the time, when a new version of Pelles issues.
Maybe not helpful - but its all I have....
John Z
No, I made a template of a project that worked well after I spoke with Pelle.
Quote from: TimoVJL on December 12, 2024, 05:58:12 PM
Pelles C have project Wizard interface
Experimental New Workspace Add-In (https://forum.pellesc.de/index.php?topic=4603.msg29141#msg29141)
I tested it at the bottom. Getting a message "A program is required to read the dll file". What kind of program is it?
EDIT:
Forgot to translate before posting the last two entries.
First I write in Swedish, then I translate it.
Wizards should copy to bin\Wizards64 folder
After restarting poide use File -> New -> Project...
Wizards ska kopieras till mappen bin\Wizards64
Efter omstart av poide använder du Arkiv -> Ny -> Projekt...
OK!
I will try it!
Now I have tested with different settings and changed the code, etc.:
- Picture 1 shows what it looks like with a function prototype at the top and the function at the bottom. It doesn't work in this old code but works in new codes.
- Picture 2 shows what it looks like with the function at the top and no function prototype. It works in this old code and in new codes.
I have compared the settings and the codes between the old code and newer codes. I can't find any difference?! So, why won't it be the same for both codes?
The reason I ask is because I intend to update codes from the year 2002 and forward so that the compiled programs work with newer Windows. But then I want the older code to appear in the editor in the same way as the newer programs.
Perhaps a functions prototypas are problem?
Some macros might be difficult for parser.
STOP THE PRESSES!
I have found the error!!!
In the older codes, I used a custom proc that looks like this:
ac_WindowMainProcLoop_1(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
In the newer codes, I use a proc that looks like this:
LRESULT ac_WindowMainProcLoopLresult_1(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
I have made a note in the file for ac_WindowMainProcLoopLresult_1 that Pelle said it must look like this. That's what I didn't remember from the email but now I remember that it was!
Now it works!
:) :)
This is what it looks like:
//Meddelandeslingans definition med LRESULT
#define ac_WindowMainProcLoop_1 LRESULT CALLBACK MessageLoopProc
//Meddelandeslingans definition utan LRESULT
#define ac_WindowMainProcLoopLresult_1 CALLBACK MessageLoopProc //Pelle rekommenderar denna = In English "Pelle recommends this one"
I left the old one in for backwards compatibility.
nice, that a your problem might be solved.
if Pelles C 12 is last version, we have to learn live with it.
Yes, it can be.
We can hope that it will handle all future Windows for many years to come.
Otherwise, I think we have to be prepared to change the programming platform. Maybe start by finding the best one out there. One that is most similar to Pelles-C but is developed by a group so that it doesn't suddenly die.
Is there a thread on the forum about other programming tools/platforms?
Hi alderman2,
QuoteIs there a thread on the forum about other programming tools/platforms?
The forum is only focused on Pelles C.
Yep!
Quote from: alderman2 on December 13, 2024, 02:16:32 PM
This is what it looks like:
//Meddelandeslingans definition med LRESULT
#define ac_WindowMainProcLoop_1 LRESULT CALLBACK MessageLoopProc
//Meddelandeslingans definition utan LRESULT
#define ac_WindowMainProcLoopLresult_1 CALLBACK MessageLoopProc //Pelle rekommenderar denna = In English "Pelle recommends this one"
I left the old one in for backwards compatibility.
Why you would think your custom macros were better than using the WinAPI
conventional macros escapes me.
Anyway, the following explains the differences for when to use CALLBACK and LRESULT CALLBACK.
CALLBACK and
LRESULT CALLBACK are both calling conventions and function types used in
Windows API programming, particularly when defining window procedures and other callback
functions in Windows applications.
CALLBACK:This is a macro defined in Windows header files (windef.h)
It typically expands to
__stdcall, which is a standard calling convention for Win32 API functions
Specifies how function parameters are passed and how the stack is cleaned up
Ensures compatibility with Windows API function calling conventions
Does
not specify a return type
LRESULT CALLBACK:Combines two things:
a) LRESULT:
The return type for the function (a 32 or 64-bit signed integer used for return values in Windows messaging)
b) CALLBACK: The calling convention (typically
__stdcall)
Commonly used for window procedure functions (WndProc)
Provides both the return type and the calling convention in one declarationExamples:
// Using CALLBACKBOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM lParam);
// Using LRESULT CALLBACK (typical for window procedures)LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);
The key difference is that LRESULT CALLBACK specifies both the return type and
calling convention, while CALLBACK only specifies the calling convention.
In most Windows programming scenarios, LRESULT CALLBACK is more commonly used,
especially for window procedures and dialog procedures.
Thanks for the clarification!
I imagine Pelle said something similar.
The reason for custom functions for almost everything I program stems from when I started programming in C in 1987 with the Amiga 500. I went from Hisoft Basic to SAS-C (I think it was called). I didn't like the hassle of C that wasn't in Hisoft Basic. I started a bit simple by baking the complexities into small files named ac_xxxxxxx_1. "ac" is short for "ASSETC" which means "Asset for C". I also found that the names of various functions didn't really indicate what they were for. Therefore, I changed the names of the ones I used. Like the function we talk about in this thread.
After a few months of working with this I was able to program almost like with Basic. It was much faster to program with my little library and everything was right right away, it rarely went wrong because everything was already right in the library. In the end I had about 100 features.
In 1993 I switched to PC. I then bought Symanteck C/C++. I converted my library to Windows. It took a very long time because Windows was significantly more complicated than the Amiga OS to program. In 1994 I was done and could start programming for real again. Since then it's been 30 years and I switched Symantec to LCC Win32 around 2000. I continued with it until I started Pelles-C around 2015. All the time I've added new features to my library and now it's up to over 800. I know I didn't do this completely by the textbook but it works and I throw together a decently large program in a day or so if it doesn't include special calculations etc. The names of my functions say what they are for, so it's easy to find the right one, etc.
But now I've got a problem. I use very basic C code in my functions. If I try to compile a 64bit program, about 300 of my functions (when I include the whole package) do not work, they are simply not compatible with 64bit. So I have to try to fix it as necessary.
I'm so used to my library now that the times I try to program without it I have to look for code that I can use etc. It also takes significantly longer because I'm not used to it. I pretty much know my library "ASSETC" by heart. I'm too old now to start something new.
A little code, the functions say what they are for. This is my template that I always use when I start a new project:
-----------------------------------------------------
//################################################################
//# NAMN = PcbDesignTool.c
//#//////////////
//# DATUM = 20241210
//# VERSION = Se i ac_WindowCreate_1 nedan
//#//////////////
//# SKAPARE = xxxxxxxx
//#//////////////
//# BESKRIVNING =
//#/////////////=
//#/////////////=
//#/////////////=
//################################################################
//## ##############################################################
//# INITIERINGSFÄLTET
//# Initieringsfältet är ytan före funktionen
//# ac_WindowMainCreate_1. Här lägger man det som
//# skall inkluderas av pre-processorn, prototyper
//# och diverse deklarationer. Programflödet strömmar
//# igenom detta fält endast när applikationen
//# startas upp.
//################################################################
//################################################################
//# INCLUDE
//# När funktioner används includeras endast det som behövs för
//# den eller de funktioner som koden innehåller.
//# Tyvärr så plockar kompilatorn med lite information från varje
//# funktion som _ASSETC_ innehåller. Detta stör inte det färdiga
//# programmet på något sätt men programmet blir större.
//#
//# För att minimera programmets storlek inkluderar man endast
//# de funktioner som behövs för ändamålet. Det kan göras när
//# man är klar med programmet.
//################################################################
//################################################################
//# INCLUDE C:\_ARBETSPLATS_\02_PROGRAM_PRODUKTION\_ASSETC_
#include "../_ASSETC_/_ac.h"
#include <wininet.h>
// * Länkar *
//#################################################
#pragma lib "Shell32.lib"
#pragma lib "Wininet.lib"
#pragma lib "kernel32.lib"
#pragma lib "user32.lib"
#pragma lib "gdi32.lib"
#pragma lib "comctl32.lib"
#pragma lib "comdlg32.lib"
#pragma lib "advapi32.lib"
#pragma lib "delayimp.lib"
//#pragma lib "netutils.lib"
// * Prototypes *
//#################################################
void Funk_09_SkapaKomponenter (HWND hwnd);
void Funk_09_Grafik (HWND hwnd);
int Funk_99_DEBUGG (HWND hwnd,int int_test1, int int_test2);
//##################################################
// * Deklarationer *
//................
//##################################################
HWND hwnd_G_Knapp_stang;
HFONT hfont_G_GrafFont;
//##################################################
// * Globala variabler *
//##################################################
//int int_G_stopp=0;
//##################################################
// * Globala konstanter *
//### ALLA ##########################################
#define KNAPP_STANG 1006
//##################################################
///// ac_WindowMainCreate_1 /////////////////////////////////////////////////////////////
int ac_WindowMainCreate_1(HINSTANCE hInst, HINSTANCE hOldInst,LPSTR lpszArg, int nWinStyle)
{
// Denna funktion måste alltid ingå i ett Windows-
// program för Cover.
// Funktionen startar programmet, anger var
// huvudlopen finns, fångar in Windowsmeddelanden
// och skickar dom vidare till huvudlopen mm.
//
// * Lokala deklarationer mm *
//Medelandestrukturen
MSG msg;
//Fönsterhandtaget
HWND hwnd;
//
//Skapa ett fönster
hwnd=ac_WindowCreate_1(hInst,"Mall",300,100,400,350,"MIN_MAX_CLO"); //
ac_WindowSetCenterPos_1 (hwnd);
// * Meddelandeslingan *
while (GetMessage(&msg, NULL, 0, 0))
{
// Meddelandeslingan har inte byggts
// in i en Cover - funktion utan
// lämnas öppen.
// Orsaken är att användare ibland
// vill och kanske måste lägga egen
// kod här för att få önskad effekt
// i sina program.
//Underlättar användning
//av tangentbord
TranslateMessage(&msg);
//Skicka meddelandet till
//ac_WindowMainProcLoop_1
DispatchMessage(&msg);
}
//Returvärde för
//ac_WindowMainCreate_1
return msg.wParam;
}
/////////////////////////////////////////////////////////////////////////////////////////
///// ac_WindowMainProcLoopLresult_1 ///////////////////////////////////////////////////////////
LRESULT ac_WindowMainProcLoopLresult_1(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
// Programmets huvudlop är en central del av
// programmets funktion. Windowsmeddelanden skickas
// igenom denna lop.
// * Huvudväxeln message *
switch (message)
{ // Styr flödet till den
// plats som passar ihop
// med meddelandet.
// Platsen anges efter
// case.
case WM_CREATE:
// Här skapas komponenter
// och annat.
// Detta meddelande körs
// endast en gång vid
// uppstart och ingen mer
// gång.
//** Lägg till ikonen **
ac_WindowSetResIcon_1(hwnd ,"MALL");
//Skapa graf-fonter
hfont_G_GrafFont = ac_GraphicCreateTextFont_1(14,5,0,FW_NORMAL,0,0,"Verdana");//Courier Verdana 15 5
//Skapa komponenterna o **
Funk_09_SkapaKomponenter(hwnd);
break;
//
case WM_SIZE:
// Flödet växlar in här
// när fönstret ändrat
// storlek.
//................
break;
//
case WM_MOVE:
// Flödet växlar in här
// när fönstret ändrat
// storlek.
//................
//Uppdaterar fösnterytan när den flyttats
ac_WindowUpdate_1 (hwnd ,"ERASED");
break;
//
case WM_PAINT:
// Flödet växlar in här
// när Windows anser att
// fönstret skall målas
// om. Grafikfunktioner
// bör alltid ligga här.
//................
Funk_09_Grafik (hwnd);
//Returnerar WM_PAINT meddelanden som inte används
return DefWindowProc(hwnd, message, wParam, lParam);
//
//################################################################
//# FÖR ATT HINDRA FLICKER och ger en ljusare färg
case WM_ERASEBKGND:
return 0;
case WM_COMMAND:
// Flödet växlar in här
// när en identifikator
// från komponenter som
// knappar,menyer, kort-
// kommandon och andra
// kontroller aktiverats.
switch(wParam)
{// Styr flödet till den
// plats som passar ihop
// med idetifikatorn.
// Identifikatorn anges
// efter case.
case KNAPP_STANG:
PostQuitMessage(0);
break;
}
break;
//
case WM_DESTROY:
// Om man utifrån program-
// koden stänger programmet
// skickar Windows detta
// meddelande till proce-
// duren och programmet
// stängs.
//................
// Avslutar applikationen
// när wParam=0
PostQuitMessage(0);
break;
//
default:
// Meddelanden som
// inte tas om hand
// i någon plats
// (case) kan tas
// om hand här.
//Returnerar message meddelanden som inte använts
return DefWindowProc(hwnd, message, wParam, lParam);
}
//
//Returvärdet för
//ac_WindowMainProcLoop_1
return 0;
}
/////////////////////////////////////////////////////////////////////////////////////////
///// Funktionsfältet ///////////////////////////////////////////////////////////////////
// Fältet här under är till för egna funktioner som
// byggs upp här. Eftersom detta fält aldrig
// genomströmas av programflödet måste en prototyp
// till funktionen placeras i initieringsfältet som
// talar om att funktionen existerar och hur den ser
// ut. Den egna funktionen kan sedan anropas från
// plats där programfödet flyter fram, exempelvis
// inifrån någon case grupp.
// Efter att funktionen gjort sitt återgår program-
// flödet till strax efter där funktionen anropades.
//Här läggs funktioner in som skall utföras
//********************************************************************************************************
void Funk_09_SkapaKomponenter(HWND hwnd)
{
/*ANVÄNDNING:
*
* Skapar komponeneterna för Utgift
*
*GLOBALA:
*
*
*
*
*
*LOKALA :
*/
hwnd_G_Knapp_stang = ac_ButtonSimpleCreate_1(hwnd, 10,310,120,20,"STÄNG","C","SHADOW",KNAPP_STANG);
}
//********************************************************************************************************
//********************************************************************************************************
void Funk_09_Grafik (HWND hwnd)
{
ac_GraphicSetTextOut_1(hwnd,20,35,"vvvvvvvvv",0,hfont_G_GrafFont,0);
}
//********************************************************************************************************
//****************************************************************************************************
int Funk_99_DEBUGG (HWND hwnd, int int_test1, int int_test2)
{
//CLOCKS_PER_SEC
//clock();
/*
clock_t start, end;
double cpu_time_used;
start = clock();
//Do the work.
end = clock();
cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;
*/
//ac_GraphicSetTextOut_1(NULL,10,500," ",0,hfont_G_GrafFont,0);
//ac_GraphicSetTextOutNummerical_1(NULL,10,500,clock()/CLOCKS_PER_SEC,0,0,0,ac_GRAY_3);
//ac_GraphicSetTextOut_1(NULL,10,430,char_HamtaPostMode,0,hfont_G_GrafFont,0);
//ac_GraphicSetTextOutNummerical_1(NULL,10,450,i,0,0,0,ac_GRAY_3);
//ac_GraphicSetTextOutNummerical_1(NULL,10,480,int_AktuellPostMode2,0,0,0,ac_GRAY_3);
//ac_GraphicSetTextOutNummerical_1(NULL,10,500,int_AktuellPostMode3,0,0,0,ac_GRAY_3);
//ac_GraphicSetTextOutNummerical_1(NULL,10,520,int_SlingaAntPostMode3,0,0,0,ac_GRAY_3);
return 0;
}
//****************************************************************************************************
EDIT:
Entered the code in the code tag and changed in 1997 to the correct one, i.e. 1987.
Hi Alderman2,
Converting to 64 bit is not extremely hard. A bit tedious, but the compiler error messages are very helpful.
I converted to 64bit not that long ago - - -
Start by archiving all of the original code (goes without saying but I'm saying....) :)
Next get and enable the Add-IN "Open project to 64bit".
Open your project as normal - then in the source code tree window on the output filename at the top of the tree right click and choose "Open project to 64bit" - when this has completed the output filename will be appended with 64.
Choose one file in the project tree and compile it. If no errors move to the next.
In many cases the error will be with windows pointers the 64 bit version usually has a P added somewhere.
Once you find the 64 bit version search and replace the entire project. If your code expects to utilize the full 64 bit 'range' then you'll want to check your own internal pointers as well. But if 32 bit size will work for your case there may be no need to change everything. There are 64 bit versions that often have 64 attached for ex: struct _wfinddata64_t c_file; and hFile = _wfindfirst64( p_fname, p_fdata );
John Z
THANKS!
I will definitely look into this suggestion! I have my own way too, maybe yours is better.
MayBe someone has already given the answer but I would try to delete all the obj files
OK
Will have to test it.