|
| Location of HTML browser control cookies |
| Débuté par Simon Phillips, 20 fév. 2026 18:35 - 3 réponses |
| |
| | | |
|
| |
| Posté le 20 février 2026 - 18:35 |
Does anyone know where the html display browser cookies are stored? At the moment, every time a user goes to a site and it asks to accept cookies, once the app is closed and reloaded, going back to to same site again asks for the cookies.
This rather dismisses the whole purpose of cookies which are supposed to stay between each visit. I gather that when the browser control is closed, the cookies are automatically deleted. If I can find out where they are stored, I can save them and when the browser closes, rewrite them.
The alternative would be an option to not delete them in the first place which ideally would be the default.
Thanks for any suggestions. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
32 messages |
|
| Posté le 23 février 2026 - 18:00 |
Hi Simon,
Since version 2025 latest update, it seems the behavior for cookie management has changed.
Cookies and cache are available at this location : C:\Users\Your user\AppData\Local\Temp\cache.cef
Before, you had a folder with the name of your app and everything went into that specific folder. On exery execution, the HTML browser control had acces to all cookies and cache.
Since 2025 latest update, it seems it is now going in a folder with the name of the app followed by the PID. Since the PID changes at every execution, it is now , to my knowledge, impossible to maintain sessions or cookies. I have no idea why such a change was made by PCSoft.
Some other users have the exact same issue on the french forum. If you have the SaaS version, I suggest you contact the tech support and see if there's a solution to that or if it is a bug they need to fix ( having a new folder with each execution is non sense imho)
If you receive any reply from the tech support, do you mind sharing it with us?
Thanks |
| |
| |
| | | |
|
| | |
| |
| Posté le 24 février 2026 - 15:00 |
Hi Maxime
Thanks, that was a great help and I have managed to make a patch which hopefully will be ok until this is fixed.
Simply add this code to your Project Initialisation. What it does is save the PID to an INI file and when the program is run the next time, it renames the directory that contains the settimngs (inc cookies) of the previous time the exe was run to the current PID. I noticed that previous directories are not actually deleted, which also means that the unused directories of the previous caches build up and take up disk space.
Please bear in mind that this will only come into effect the second time an app is run after adding this as the ini file will be empty on the first run, so it will not know what the PID of the previous app run was. However, after that it should be ok.
This is not an elegant solution, but hopefully will cure this issue for the time being
nCurrentPID, nLastPID is int
sCacheParent, sCacheDir, sNewCacheDir is string
nCurrentPID = ExeGetPID()
sCacheParent = fTempDir + "cache.cef"
IF fDirExist(sCacheParent) THEN
nLastPID = INIRead("Cookies","LastPID", 0,fCurrentDir() + "\cookies.ini") // This will create a ini file in the current directory. Change to suit.
IF In64bitMode() = True THEN
sCacheDir = sCacheParent + "\wdtst64_user" + nLastPID
ELSE
sCacheDir = sCacheParent + "\wdtst_user" + nLastPID
END
END
IF fDirExist(sCacheDir) THEN
IF In64bitMode() = True THEN
sNewCacheDir = fTempDir + "cache.cef\wdtst64_user" + nCurrentPID
ELSE
sNewCacheDir = fTempDir + "cache.cef\wdtst_user" + nCurrentPID
END
fDirRename(sCacheDir,sNewCacheDir)
END
//Lastly write the PID of the currently running exe to the INI so any cookies saved will be transferred to the next occurance of the app
INIWrite("Cookies","LastPID",nCurrentPID,fCurrentDir() + "\cookies.ini") |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
32 messages |
|
| Posté le 24 février 2026 - 17:22 |
Simon Phillips a écrit :
Hi Maxime
Thanks, that was a great help and I have managed to make a patch which hopefully will be ok until this is fixed.
Simply add this code to your Project Initialisation. What it does is save the PID to an INI file and when the program is run the next time, it renames the directory that contains the settimngs (inc cookies) of the previous time the exe was run to the current PID. I noticed that previous directories are not actually deleted, which also means that the unused directories of the previous caches build up and take up disk space.
Please bear in mind that this will only come into effect the second time an app is run after adding this as the ini file will be empty on the first run, so it will not know what the PID of the previous app run was. However, after that it should be ok.
This is not an elegant solution, but hopefully will cure this issue for the time being
nCurrentPID, nLastPID is int
sCacheParent, sCacheDir, sNewCacheDir is string
nCurrentPID = ExeGetPID()
sCacheParent = fTempDir + "cache.cef"
IF fDirExist(sCacheParent) THEN
nLastPID = INIRead("Cookies","LastPID", 0,fCurrentDir() + "\cookies.ini") // This will create a ini file in the current directory. Change to suit.
IF In64bitMode() = True THEN
sCacheDir = sCacheParent + "\wdtst64_user" + nLastPID
ELSE
sCacheDir = sCacheParent + "\wdtst_user" + nLastPID
END
END
IF fDirExist(sCacheDir) THEN
IF In64bitMode() = True THEN
sNewCacheDir = fTempDir + "cache.cef\wdtst64_user" + nCurrentPID
ELSE
sNewCacheDir = fTempDir + "cache.cef\wdtst_user" + nCurrentPID
END
fDirRename(sCacheDir,sNewCacheDir)
END
//Lastly write the PID of the currently running exe to the INI so any cookies saved will be transferred to the next occurance of the app
INIWrite("Cookies","LastPID",nCurrentPID,fCurrentDir() + "\cookies.ini")
You know, sometime, solutions don't always need to be elegant, they just have to work 
Thank you very much for sharing this workaround. I am sure this will come in handy until PCSoft has an official fix for this issue!
If I can add something to your code : you hardcode "wdtst_user" in your directory name. Keep it mind this is the name of the exe when testing using the Windev dashboard.
So I suggest we add a string that identify the app name and use it in the sCacheDir and sNewCacheDir variables later on.
e.g. :
Adding this - - > sAppName is string = "Insert your app name here"
And then in your code for sCacheDir (example again):
sNewCacheDir = fTempDir + "cache.cef\" + sAppName + nCurrentPID
In this case, I don't think you'd need to check if the app is 32 or 64 bit, unless you give a different name for your 32 and 64 bit builds.
- Maxime |
| |
| |
| | | |
|
| | | | |
| | |
|