-
Content Count
1298 -
Joined
-
Last visited
-
Days Won
29
Posts posted by Dave Nottage
-
-
25 minutes ago, PeterPanettone said:There would be many lines. An automatism would be faster than adding the commas manually
How are those lines entered? If by typing, why not just type the commas as the code is being typed? If they're generated, why not generate the lines with commas in the first place?
-
Have you traced through the code to see where it fails? Does it reach the first line in the anonymous method?
-
I use a macOS VM (on a macOS host) to try out new versions of Xcode, macOS etc. No problems at all using Xcode 10.2 with:
Debugging to an iPhone X
Deploying an app store version (i.e. set Configuration to App Store, use Deployment Manager to deploy)
-
What version of build tools are you using? i.e. in the Delphi SDK Manager, what is the path for example, for aapt.exe?
-
3 hours ago, B See said:However, when I change the two items to ("26", %targetSdkVersion … %), ("26","28"), ("28","28") or (%targetSdkVersion%, %targetSdkVersion%
Can you be a bit more explicit about what you are actually changing? Preferably, show the before and after, even if it's the whole manifest.
-
I expect this may be rather difficult to be implemented in an expert without having it totally separate from the Structure View itself, because there is only one TVirtualStringTree which reloads, dependent on whether Code or Design is selected.
-
On 3/7/2019 at 11:21 AM, Remy Lebeau said:extern "C" __declspec(dllexport) int Load(PDLLLINK pLink);
Or:
extern "C" int __declspec(dllexport) Load(PDLLLINK pLink);
Neither of those compile, giving the same error: Declaration terminated incorrectly.
It compiles OK omitting: extern "C", however the Load function is not exported, either. Could this be due to the .lib not being linked? I can name Load as Loadx instead, and the project still compiles.
I'm using ObjConv from here: https://agner.org/optimize/ to convert the original .lib file to OMF format. C++Builder does not complain about the file being linked, however I'm wondering whether it is sufficient for it to use.
-
Please specify what version of Delphi (if different to your tagged version of 10.2 Tokyo), Xcode, iOS SDK, and iOS on the device.
-
Having trouble with the declaration:
extern "C" __declspec(dllexport) int Load(pLink: PDLLLINK);
Gives: Declaration terminated incorrectly.
-
3 minutes ago, Remy Lebeau said:Those modifiers can be applied directly to the function declaration.
But, are you referring to a VS static library that you want to link inside your C++Builder DLL?
Yes, so we'll give that a shot; thanks!
-
1 hour ago, Remy Lebeau said:I prefer to use 'extern "C"' and __declspec(dllexport) in the DLL's source code instead
The trick here is that the function that needs to be exported from the DLL is actually in the .lib. Is it possible to use extern "C"' and __declspec(dllexport) with it?
-
1 hour ago, Remy Lebeau said:In the Project Options, in the C++ Compiler section, there is a "Use 'classic' Borland compiler" option.
OK, we're a step closer. The DLL compiles, however now I need to export a function contained in the .lib, namely: Load. I've created a .def from a VS C DLL that I know works:
LIBRARY WSCTX.DLL EXPORTS Load @1 ; Load
..and added it to the project, however I now receive this error:
[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.
Either my Google-fu has once again disappeared, or I seem to be alone in ever receiving it using C++Builder?
-
12 minutes ago, Remy Lebeau said:What kind of errors exactly?
First one is: "[bcc32c Error] Api_HpcCallTable.h(181): pasting formed '->Hpc_Trace_AddClassId', an invalid preprocessing token" for this code:
int HPC_CALL_TABLE_STUB( Hpc_Trace_AddClassId, (char* pszClassName), pszClassName);
Where HPC_CALL_TABLE_STUB is defined as:
#define HPC_CALL_TABLE_STUB( FuncName, ParamType, ...) \ __inline static FuncName##_Stub ParamType \ { \ if(g_pHpcCallTable && NULL != g_pHpcCallTable->##FuncName) \ { \ return( (g_pHpcCallTable->##FuncName)(__VA_ARGS__)); \ } \ \ return( 0); \ }
15 minutes ago, Remy Lebeau said:Also, which version of C++Builder are you using? Which of its many C++ compilers specifically are you using? Are you using a compiler that is compatible with the C++ version that the VS code is targeting?
Great questions. I am using C++Builder 10.3.1 Community Edition. Am I able to choose a different compiler depending on the situation? If so, how? As advised, I created a DLL project and chose C as the language. I have extremely limited experience with C++Builder
17 minutes ago, Remy Lebeau said:That would imply that the .lib file is probably a static library instead of an import lib for a DLL.
That seems logical to me. The issue here is that C++Builder will not link to the .lib file as-is, and I assume it's because it's in COFF format. I tried to use COFF2OMF to convert it, however that does not appear to produce a .lib that contains all the required code
-
My Google-fu seems to be off at the moment.
I have a DLL project that was originally for Visual Studio that I'm attempting to port to C++Builder. I'm struggling to find any tips on making this migration, other than apparently some time ago C++Builder had a method of importing Visual C++ projects. Does any method exist for importing such a project, or perhaps a site that gives tips about it?
I've created a C-based DLL project in C++Builder and am attempting to include the original VS (C-based) code, however I'm receiving a bunch of compiler errors, which are different each time I load the project and hit "Build".
The motivation for moving it from VS is to have the ability to include Delphi code in the project.
Additional issue: I have a .lib file that is used in the VS project, but no corresponding .dll, so that I can use implib to import a .lib that C++Builder will link to. Is there a way I can create a .dll in VS so that everything in the .lib is imported?
-
https://community.embarcadero.com/article/news/16638-rad-studio-august-2018-roadmap
That was the last roadmap published. If unchanged, there are things slated for 10.3.x that were not included in 10.3.1, so they may end up in a 10.3.2 release, e.g: macOS 64
- 1
-
Thanks! Given the code in TAndroidHTTPClient.DoExecuteRequest, it would seem that somehow a connection is being made before DoExecuteRequest is executed, because setRequestProperty is definitely called before connect (and it is the only place connect is called). It might be that DoExecuteRequest is somehow being called twice, however I could not say without a test project.
-
I referred to the callstack, not the actual code. The Callstack window is the one in the very top left of your first picture. It's possible to copy/paste what is inside that window.
-
When the crash occurs as per your first image, can you click "Break", so that the callstack shows, please? Then present here what the callstack actually shows (preferably paste the text, rather than a picture)
-
1 hour ago, Remy Lebeau said:There may not even be an exception being thrown at all
What else might it be doing, if the call to the Delphi DLL does not return "properly"?
-
1 hour ago, Remy Lebeau said:- if the exception handler is not being called, then either there is no exception being thrown at all, or it is not an SEH-based exception.
Thanks for the other tips. For this one, I still don't know whether or not I have coded the exception handler correctly, or is it just the IntToStr thing that's a problem?
-
6 hours ago, Remy Lebeau said:No, it is not
What is the correct way?
6 hours ago, Remy Lebeau said:You will have to use the debugger to verify one way or the other.
Unfortunately, that is easier said than done. The process which loads the DLL runs only when an app is run on Citrix, and it makes the calls to DriverOpen etc immediately, and once the process fails it needs to be restarted, which makes it nigh on impossible to attach to the process that is loading the DLL, let alone debug it.
6 hours ago, Remy Lebeau said:- there is a calling convention mismatch in how DelphiDriverOpen() is declared in both languages.
- the Delphi DLL is corrupting the call stack.
- an uncaught exception is being thrown
For the first point: I'll need to double check that tomorrow, however given that everything works 100% of the time on most machines, I figure it's unlikely.
For the second point: in what ways might this happen?
For the third point: That's the reason why I have the exception handler, if I can make it work -
12 hours ago, Remy Lebeau said:That would imply that the Delphi DLL is not coded properly for the Citrix driver API, since Delphi can certainly produce C-compatible DLLs.
Regarding going down the route of a "pure" Delphi DLL: The DLL needs to link to a .lib file that is provided with the SDK. Since Delphi cannot link to .lib files, I needed to extract the .obj file (there is only one in the .lib) and link to that. There are 9 symbols that need to be linked to: 2 are "direct" static links that look like this:
function _Load(pLink: PDLLLINK): Integer; cdecl; external name '_Load'; function VdCallWd(pVd: PVD; ProcIndex: USHORT; pParam: PVOID; puiSize: PUINT16): Integer; stdcall; external name '_VdCallWd@16';
I'm not sure of the correct terminology for it, however the other 7 symbols are the functions that need to be "implemented", including DriverOpen, however because of name mangling, they're exported with symbol names like this (e.g.): _DriverOpen@12. Since it's impossible to name Delphi functions with an "@" symbol, I used ObjConv to rename the symbols, removing the @12 and while I was at it, the underscore. This results in, for example, DriverOpen being declared thus:
function DriverOpen(pVd: PVD; pVdOpen: PVDOPEN; puiSize: PUINT16): Integer; stdcall;
I cannot add "external" and "name" for these functions because they need to be "implemented", rather than "direct" static links. Again, not sure of the exact terminology for this distinction.
In this "pure" Delphi DLL mode, everything compiles OK and Citrix loads the DLL successfully, however for one reason or another it never calls DriverOpen (at all, in this mode), which apparently (as per my original post) it usually calls first. It does however call the DriverInfo function, and does so successfully. Note that the only function that is exported is the Load function (as per their C examples). The Load function is documented as doing the work of setting up a call table to the other functions.
Thanks regarding the HND type and pLibMgrCallTable ; I have now corrected that. As far as the "pure" mode goes, this made no difference, however.
Back to the "conduit" mode: I had set up some logging to dump what values are coming into the C DLL, and into the Delphi DLL, and see what goes back from Delphi to C, in case there was something untoward happening, and I've discovered that although the DriverOpen function in the Delphi DLL actually completes, it does not return to the calling point in the C DLL, i.e. there's a problem somewhere in between. I put in an exception handler, but I guess it's not right:
char* IntToStr(int Number) { char Result[50]; sprintf(Result, "%d", Number); return(Result); } int HandleException(unsigned int code, struct _EXCEPTION_POINTERS *ep) { char Msg[512]; strcpy(Msg, "Exception code : "); strcat(Msg, IntToStr(code)); OutputDebugString(Msg); return EXCEPTION_EXECUTE_HANDLER; } int DriverOpen(PVD pVd, PVDOPEN pVdOpen, PUINT16 puiSize) { OutputDebugString("WSCitrix Conduit DLL DriverOpen called"); if (LoadDelphiDLL()) { __try { int result = DelphiDriverOpen(pVd, pVdOpen, puiSize); OutputDebugString("WSCitrix Conduit DLL DriverOpen returned from Delphi"); return(result); } __except(HandleException(GetExceptionCode(), GetExceptionInformation())) { } } }
i.e. it calls DelphiDriverOpen (which completes in the Delphi DLL), but never reaches the subsequent OutputDebugString
My limited C skills are probably shining through 😉 -
A while ago, I managed to make the whole Citrix Virtual Channel thing work, i.e. I constructed a C DLL much like the examples from the Virtual Channel SDK, and just "re-route" the calls to a DLL written in Delphi (long story short: so far it has been the only way I could make this work).
The problem now is that on some machines, the Citrix startup sequence fails, and I'm at a loss as to why. The normal sequence goes like this:
- A user starts an app from within the Citrix environment
- Citrix checks which virtual channels are registered with the system, which includes ours (the DLL that is "registered" with Citrix is the C-based DLL)
- Citrix loads the C-based DLL, and calls the DriverOpen function
- The DriverOpen function in the C-based DLL loads the Delphi DLL and obtains the method address for the corresponding DriverOpen function in the Delphi DLL
- The C-based DLL calls the DriverOpen function in the Delphi DLL, the Delphi function "does its thing", and returns the value back to the C-based DLL, which passes that result back to Citrix.
- The next part of the sequence is that Citrix calls 2 other functions, DriverSetInformation and DriverInfo. These are "re-routed" in the same manner as DriverOpen
The problem is that Citrix throws an error after step 5 completes - it is known that the Delphi DLL finishes its work with DriverOpen successfully (through logging). As indicated above, this problem happens only on some machines, so I'm wondering whether there's something I might be able to look for that is a "gotcha" that might be causing the problem? Sadly, Citrix's diagnostics (or lack thereof) are particularly woeful - there are no clues given as to what the issue might be, other than a cryptic error message:
Error 1021: Invalid Handle
That has no help for it.
Keep in mind that this process all works on most machines; all are Windows 10 (same build). I'm hoping to be able to resolve this without having to divulge any source code.
Edit:
On thinking a bit more, I figure that it might help to show my conversion from C to Delphi of one of the types being passed to DriverOpen. The function itself is declared like this in C
int DriverOpen(PVD pVd, PVDOPEN pVdOpen, PUINT16 puiSize)
Note that the pVdOpen parameter is not referenced at all within the function in the Delphi DLL, however I figure if I might have that wrong, it might be causing some problem. The pVd parameter is used in all functions. These are the relevant types in their C versions and what I've translated them to in Delphi:
C
#define MODULE_LENGTH 13 #define PWFCAPI TYPEDEF_CDECL TYPEDEF_FAR * typedef UINT32 (PWFCAPI PLIBPROCEDURE)(); typedef PVOID HND; typedef struct _DLLLINK { /* NOTE: 1st six elements must be same as MINIDLL */ USHORT Segment; /* starting seg of mem allocated for dll (aligned) */ USHORT DllSize; /* actual size of dll in paragraphs */ USHORT ProcCount; /* number of procedures in call table */ PVOID pProcedures; /* pointer to procedure call table */ PVOID pData; /* pointer to dll data structure */ PUCHAR pMemory; /* pointer to malloced memory (not aligned) */ BYTE ModuleName[MODULE_LENGTH]; /* client module name (8.3) */ LPVOID pLibMgrCallTable; /* Pointer to LibMgrTable (input) */ USHORT ModuleDate; /* module date in dos format */ USHORT ModuleTime; /* module time in dos format */ ULONG ModuleSize; /* module file size in bytes */ struct _DLLLINK * pNext; /* pointer to next DLLLINK structure */ ULONG DllFlags; /* DLL flags (embed..) */ /* Everything after here is not included for the ModuleEnum call. */ HND LibraryHandle; } DLLLINK, * PDLLLINK; typedef struct _VDOPEN { LPVOID pIniSection; PDLLLINK pWdLink; ULONG ChannelMask; PLIBPROCEDURE pfnWFEngPoll; PLIBPROCEDURE pfnStatusMsgProc; HND hICAEng; } VDOPEN, FAR * PVDOPEN;
Delphi:HND = THandle; PLIBPROCEDURE = function: UINT32; cdecl; PDLLLINK = ^DLLLINK; _DLLLINK = record Segment: USHORT; DllSize: USHORT; ProcCount: USHORT; pProcedures: Pointer; pData: Pointer; pMemory: PUCHAR; ModuleName: array[0..12] of Byte; pLibMgrCallTable: ^DWORD; ModuleDate: USHORT; ModuleTime: USHORT; ModuleSize: ULONG; pNext: PDLLLINK; DllFlags: ULONG; LibraryHandle: HND end; DLLLINK = _DLLLINK; PVDOPEN = ^VDOPEN; __VDOPEN = record pIniSection: Pointer; pWdLink: PDLLLINK; ChannelMask: ULONG; pfnWFEngPoll: PLIBPROCEDURE; pfnStatusMsgProc: PLIBPROCEDURE; hICAEng: HND end; VDOPEN = __VDOPEN;
-
Going by the source, it appears it is called when the IDE first goes "idle", and it fires off a thread to do the check, so I doubt the delay is from the "phone home" check.
FWIW, I see no noticeable delay with version 1.1.6.959
[Fmx, iOS] Vibration, which Framework for which devices ?
in Cross-platform
Posted
Given one of the answers in the SO link, it sounds (pun intended) like AudioServicesPlaySystemSound is your best bet to ensure it works on all devices. You just need to import the function, something like this:
uses iOSapi.CoreFoundation; const libAudioToolbox = '/System/Library/Frameworks/AudioToolbox.framework/AudioToolbox'; procedure AudioServicesPlaySystemSound(inSystemSoundID: UInt32); cdecl; external libAudioToolbox name _PU + 'AudioServicesPlaySystemSound';