[fpc-pascal] Doc file errors
Hi, I spent time yesterday trying to look up DOS commands on the FPC website and was unable to reference DosExitCode, Exec and some others I knew should have been there on the live pdf files. They're popping up in the PDF by search with a numeric hyperlink, but the hyperlinks are not referencing to the commands accurately. I tried to download the help files at the ftp site and found ftp and First Mirror both down. I hit the USA mirror and finally got a copy of the HTML files and ran AgentRansack on them and was able to locate Dos commands and links "were" correct on those. Is this known already and do we enter Doc errors in the bug list or what is the correct process for verification or notification? Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc exec/shell vs win32API
Hi, On XP/98, I've coded some successful file and directory action a couple of different ways with exec and the native Dos commands in FP that are working OK, but as I approach having to modify some current Windows run-time, the adopted Comspec, is not going to let me get to the current Win32 runtime with Exec. Seeking and killing some processes, launching a couple of third party process manipulation apps and reading back results from those is the next step to what I'm doing. Q1.) Will the process.class access the current win32 environment for this, or is process also explicitly an adopted environment? Q2.) Otherwise any suggestions of libs/wrappers/tutorials to Win32api for basic process handling might offer a good start if anyone has suggestions? I looked through the contributed units and googled quite a few pages but really didn't find much in that regard, unless I'm overlooking the obvious. Thanks for any pointers, (no pun intended) Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] PIC returns in 2.4?
Hi, Currently the FAQ shows Position Independent Code generation is "currently broken" in the creation of shared libraries, (Future Plans shows 2.4 working to recover it). I tried to search the web site but the search system gives an error right now. Please, what version did PIC last work in for Linux and Windows? Does availability of testing PIC look far off or near future? Thanks always, Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC 2.0.0 - Win32 and MySql 4.xx
Hi, I've battled over trying to figure out how to compile units and examples in FPC for MySql, until I'm blue in the face for hours. There are few examples or comments on Google that afford any straight answers, otherwise conflicted with older revs. I'm working from Dev-Pascal's IDE, on FPC 2.0.0. 1. Does this have to be done in Gnu, or will FPC handle the compile? 2. I'm finding units, packages and examples, but can't seem to find how to cause an FPC assemblage to work.? 3. I understand there's a special utility for compiling make related. Is this contained in the FPC pkg? It's gone from the website. 4. Do I need to download client-lib from MySql, or can I use one in their distro? 5. Does a libmysql??.dll replace the need for the client-lib from MySql? Can users here offer some stepwise direction to get me off the ground here, please? 8:::( Thank you in advance. I continue to pour over the docs on this. Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] MSG variable type, Windows GUI
Hi, I encountered an FPC Win32, tutorial that uses the a declaration of variable "msg", declared as a MSG type, shown below. Dev-Pas IDE, FPC 2.00 gives an "error in type definition" and I find no doc references to MSG, variable type. Was this an earlier convention in FPC and if so, how was it replaced? Thanks, Mike [clip] program Win32_Source03; uses windows; const AppName = 'Win32/ FPC - Source 03'; VAR active : BOOLEAN; msg : MSG; hWindow,msg : hwnd; [end clip] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re:MSG variable type, Windows GUI
Luiz wrote: active : BOOLEAN; message : MSG; hWindow,msg1 : hwnd; this should work Luiz Thumbs up Luiz, thank you. The second usage with msg1 was a typo on my part. Understandable that this was changed in the compiler. ;) active : BOOLEAN; mssg : MSG; hWindow : hwnd; Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] C++ > C wrapper callback > Pascal
Hi List,
I'm probably over my head on this one and some of the FPC forum entries
talk about limited functionality toward C++, but here goes.
A Windows pascal application is recieving data from a C++, VisC API,
which is set up as a class, and a conventional C wrapper, attempting to
extend functionality into Pascal. C++ and C are vis 4.2 MFC
The application crashes on the callback shown below. The odd thing is
that it crashes, simply using a string allocation in pascal. Tried
ansistring and others. Assumption, is that the callback is possibly not
configuring memory or address pointer correctly and then the String
allocation is landing off location by register and stomping on a relative
memory location.
Is this a valid implementaiton or outside the scope of FPC?
Thanks in advance for any suggestions.
THE PASCAL is called back to, in the following:
function L1_Callback(quote : pointer) : integer; stdcall; export;
var
bid_price : double;
s : string;
begin
SendMessage(listbox, LB_ADDSTRING, 0, longint('L1 Callback'));
SendMessage(listbox, LB_ADDSTRING, 0, longint(Get_secsym(quote)));
bid_price := Get_l1_BidPrice(quote);
//s := 'test message'; // This will crash!
//s := FloatToStr(bid_price); // Intended call crashes!
//SendMessage(listbox, LB_ADDSTRING, 0, longint(s));
end;
THE C WRAPPER has the following:
int CDasApiEx::OnQuote(st_L1Quotes *pQuote)
{
if(m_pL1Callback) (*m_pL1Callback)(reinterpret_cast(pQuote));
if(m_hWndCallback)
::SendMessage(m_hWndCallback,1,0,reinterpret_cast(pQuote));
return 0;
}
Mike
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] C++ > C wrapper callback > Pascal Continues
Urbansound wrote:
Hi List,
A Windows pascal application is recieving data from a C++, VisC API,
which is set up as a class, and a conventional C wrapper, attempting to
extend functionality into Pascal. C++ and C are vis 4.2 MFC
function L1_Callback(quote : pointer) : integer; stdcall; export;
One thing that comes into my mind is that you should make sure that
"integer" above really means what you want. "integer" is either 16-bit
or 32-bit,
Also, do you really want to put "export" here ? It's harmless, but
unnecessary, if you're only passing a pointer to L1_Callback to some
other C routine.
Thank you to Michalis Kamburelis...
clipped this down (and still too long)...
Yes the integer sizes were confirmed = 32 (win32 gui) and the export was
added simply attempting to force a change in memory allocation, along with
pre-initializing variables. Among other things, Delphi mode was tried and
we boiled the problem down to two lines of code in particular, commented
below. As well, we hand converted the Pascal app to C, in order to test the
C_wrapper, compiled on GCC and the same calling conventions and methods work
fine in C-GCC, but fail in Pascal. VERY ODD. Wrapper works fine.
Review:
//--
PROBLEM IS BELOW and either comment line removed, will crash = RT217...
I suspect the problem is pointer "quote", somehow is crashing registers.
FUNCITON HEADER:
function SetL1Callback(func_addr : pointer) : integer; stdcall; external
'DasRapper.dll' name 'SetL1Callback';
>>>>> where SetL1Callback(@L1_Callback); is set in the pascal main
area.<<<<<
FUNCTION CALL TO WRAPPER
function L1_Callback(quote : pointer) : integer; stdcall;
var
bid_price : double = 0.0;
s : ansistring = '';
begin
SendMessage(listbox, LB_ADDSTRING, 0, longint(pchar('L1 Callback')));
SendMessage(listbox, LB_ADDSTRING, 0, longint(Get_secsym(quote)));
bid_price := Get_l1_BidPrice(quote);
//s := FloatToStr(bid_price); // This will crash!
//SendMessage(listbox, LB_ADDSTRING, 0, longint(pchar(@s)));
end;
//
PASCAL WRAPPER function being called is below
DllExport void SetL1Callback(TL1Callback p) { DasApi.m_pL1Callback=p; };
SUMMARY:
There seems to be nothing I can find that would cause a Runtime 217 in the
layout and now finding C conversion of same is working.
Can anyone else please confirm if this should work, or is a bug report be in
order??
Thanks to all, whoever may have additional ideas. Mike
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] C++ > C wrapper callback > Pascal Continues
//
PASCAL WRAPPER function being called is below
DllExport void SetL1Callback(TL1Callback p) { DasApi.m_pL1Callback=p; };
SUMMARY:
There seems to be nothing I can find that would cause a Runtime 217 in
the
layout and now finding C conversion of same is working.
Can anyone else please confirm if this should work, or is a bug report be
in
order??
Peter Vreman wrote:
A bug report is only in order if there are complete sources otherwise it
can't be reproduced.
Thanks to all, whoever may have additional ideas. Mike
Are the pascal units are initialized? A call to FPC_INITIALIZEUNITS is
required otherwise the memorymanager etc. will not work.
Thank you Peter,
From the scant references I have found regarding FPC_INITIALIZEUNITS Peter,
I would think you have the likely cause. Unfortunately, the 2.0.0. Docs,
nor the Web docs make reference to the function, (if it is a function), and
Google seems to have only few examples.
Where can I find documentation on FPC_INITIALIZEUNITS and is it valid in
fpc-2.0.0, being the docs don't refer it?
Regards,
Mike
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] C++ > C wrapper callback > Pascal Continues
Reply Peter and Tomas, is below, each... Thread pruned.
2. Re: C++ > C wrapper callback > Pascal Continues (Peter Vreman)
3. Re: C++ > C wrapper callback > Pascal Continues (Tomas Hajny)
--
Message: 2
Date: Wed, 27 Jul 2005 14:26:57 +0200 (CEST)
It is an internal function implicitly called by the compiler.
The s call in the message line was converted to a "pointer(s)". I found the
FPC_INITIALIZEUNITS at Main, in the ASM output and understand now that the
compiler handles this fully and that FPC_INITIALIZEUNITS could not be the
issue. Perhaps this thread will help others new to FPC to know this too on
the chance they may research it. Thank you. Present code is at bottom to
thin down the thread.
Tomas below, may be onto it, as a threading issue. Thanks still for your
help. Mike
Well, maybe I misunderstood the original post, but my understanding was
that it's about a _Pascal_ program calling some C function (which is in
fact just a wrapper for C++, but that shouldn't matter) and passing some
other Pascal function as a callback. If this is the case and the callback
function runs within the same thread as the block calling the C wrapper,
Pascal units should be initialized since the main Pascal program startup,
shouldn't they? If a new thread is started by the C++ program, you need to
perform (Pascal) initialization of the thread (probably on the first entry
to the callback function). Could you clarify this, please (link to the
complete sources or preferrably their simplified but still compilable
version would probably serve the best as already pointed out by Peter)?
Tomas
Thanks Tomas.
1) Current function is below, due to pruning the thread.
1) Clearly I was off course on FPC_INITIALIZEUNITS
2) You're understanding is correct C++api > C+wrpr > Pascal as callback
The wrapper is actually C code in a .cpp, for functionality
3) The API is multi-threaded, having dl'd a thread monitor, showing as many
as 5 threads spawened to the API and accompanied executable. As well, a
call back occurs by default from the API, at runtime, suggesting it fires
off a single dummy callback event.
4) Can you suggest an approach on the Pasacl Initialization to the thread
and/or some of the areas I should be looking up toward doing the work?
Google is my friend. ;-)
Thank you again. Mike
//--- Current function model below here
function L1_Callback(quote : pointer) : integer; stdcall; export;
var
bid_price : single = 0.0;
s : ansistring = '';
begin
SendMessage(listbox, LB_ADDSTRING, 0, longint(Pchar('L1 Callback')));
// -- either commented below will cause crash
//SendMessage(listbox, LB_ADDSTRING, 0, longint(Get_secsym(quote)));
//bid_price := Get_l1_BidPrice(quote);
s := FloatToStr(bid_price);
SendMessage(ListBox,LB_ADDSTRING,0,Longint(pointer(s)))
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] C++ > C wrapper callback > Pascal Continues UPDATE
See bottom post
- Original Message -
From: "Urbansound" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, July 27, 2005 11:05 PM
Subject: C++ > C wrapper callback > Pascal Continues
Reply Peter and Tomas, is below, each... Thread pruned.
2. Re: C++ > C wrapper callback > Pascal Continues (Peter Vreman)
3. Re: C++ > C wrapper callback > Pascal Continues (Tomas Hajny)
--
Message: 2
Date: Wed, 27 Jul 2005 14:26:57 +0200 (CEST)
It is an internal function implicitly called by the compiler.
The s call in the message line was converted to a "pointer(s)". I found
the FPC_INITIALIZEUNITS at Main, in the ASM output and understand now that
the compiler handles this fully and that FPC_INITIALIZEUNITS could not be
the issue. Perhaps this thread will help others new to FPC to know this
too on the chance they may research it. Thank you. Present code is at
bottom to thin down the thread.
Tomas below, may be onto it, as a threading issue. Thanks still for your
help. Mike
Well, maybe I misunderstood the original post, but my understanding was
that it's about a _Pascal_ program calling some C function (which is in
fact just a wrapper for C++, but that shouldn't matter) and passing some
other Pascal function as a callback. If this is the case and the callback
function runs within the same thread as the block calling the C wrapper,
Pascal units should be initialized since the main Pascal program startup,
shouldn't they? If a new thread is started by the C++ program, you need
to
perform (Pascal) initialization of the thread (probably on the first
entry
to the callback function). Could you clarify this, please (link to the
complete sources or preferrably their simplified but still compilable
version would probably serve the best as already pointed out by Peter)?
Tomas
Thanks Tomas.
1) Current function is below, due to pruning the thread.
1) Clearly I was off course on FPC_INITIALIZEUNITS
2) You're understanding is correct C++api > C+wrpr > Pascal as callback
The wrapper is actually C code in a .cpp, for functionality
3) The API is multi-threaded, having dl'd a thread monitor, showing as
many as 5 threads spawened to the API and accompanied executable. As
well, a call back occurs by default from the API, at runtime, suggesting
it fires off a single dummy callback event.
4) Can you suggest an approach on the Pasacl Initialization to the thread
and/or some of the areas I should be looking up toward doing the work?
Google is my friend. ;-)
Thank you again. Mike
//--- Current function model below here
function L1_Callback(quote : pointer) : integer; stdcall; export;
var
bid_price : single = 0.0;
s : ansistring = '';
begin
SendMessage(listbox, LB_ADDSTRING, 0, longint(Pchar('L1 Callback')));
// -- either commented below will cause crash
//SendMessage(listbox, LB_ADDSTRING, 0, longint(Get_secsym(quote)));
//bid_price := Get_l1_BidPrice(quote);
s := FloatToStr(bid_price);
SendMessage(ListBox,LB_ADDSTRING,0,Longint(pointer(s)))
end;
Update:
Per Tomas suggestions:
Among our C equivelent of the Pascal program, we did the following, which
confirms that the C+ callback and Pascal, are on the same, single thread,
which was confirmed with a thread monitoring tool during operation. (See
comment at bottom).
//-Thread compare
void ShowThreadInfo(char* id)
{
char s[80];
sprintf(s,"%s Thread ID: %08X Thread Handle:
%08X",id,GetCurrentThreadId(),GetCurrentThread());
SendMessage(listbox, LB_ADDSTRING, 0, (LPARAM)s);
}
int _stdcall L1_Callback(void* quote)
{
//double bid_price;
char s[100];
ShowThreadInfo("Callback");
//--
Given that an equivelent C program, (built by modifying the Pascal program
to suit C syntax/method), runs without a problem and yet there is no evident
reason code-wise for the problem, what is the next step in resolving the
matter. I can use GDB, though I am new to it, as of this issue. If someone
is willing to give me a guide on what command/data gdb can afford us, I'd
certainly make the effort here, unless there are other suggestions? This is
fpc 2.00, so I'm current w/stable.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Extended float to single and pchar types
Hi, I have a stdcall reference to a c based dll. called target.dll In c the setup is ... float Get_l1_BidPriceSingle(void* p); The Pascal reference is... function Get_l1_BidPrice(p : pointer) : single; stdcall; external 'target.dll' name 'Get_l1_BidPrice'; The end result is to allow a usage in win32 as ... SendMessage(listbox, LB_ADDSTRING, 0, longint(Pchar(s))); The c reference is a 'Single' float, but each time I make refernece to data conversion, errors tell me that the reference to the call is returning a 10 bit "Extended" float which fails, appearing to be a default autotype conversions to an extended 10 byte float, in fpc. Converted data as an "Ansistring" seems to fail any type of conversion, as a runtime 207 crash. If I store Str conversions to a "shortstring", I can format the fp and convert it to a fixed decimal rounded output, xxx.yyy, but using length() direct or pointer access, still pulls the 0 byte and extra characters of the string into any other converted output, requiring array managment and parsing. Is there a way to take an "extended" FP and covert it ultimately to a Pchar that would allow messaging to win32 list boxes or similar to a litteral equivelent behaviour, without having to run through all the symantics of array management? OR Can one circumvent the auto-typing to extended, so that single or double would behave to conversion methods like FloatToStr() that I could then type over to pchar and serve the same purpose? Clearly I'm not yet comfortable with string manipulation in Pascal, so an example would go a long way toward getting me to where I can do the work myself. Thanks as always. Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extended float to single and pchar types
- Original Message - From: "Matt Emson" <[EMAIL PROTECTED]> To: "Urbansound" <[EMAIL PROTECTED]>; "FPC-Pascal users discussions" Sent: Tuesday, August 02, 2005 11:26 AM Subject: Re: [fpc-pascal] Extended float to single and pchar types Are you sure it is stdcall? Quite often it's the calling convention that messes up the calling of a C DLL. Could it be safecall or cdecl? Which compiler made the DLL? Well... I was sure until it was pointed out that I needed to change ALL of the declarations, not just the one I was accessing, which means that other stdcall declarations were likely stepping on the stack or heap, while I was focused only on the one call I changed. DOAH! You were correct in your observation. Thank you Matt. Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] HeapError variable access
Hi, I'm working with a unit someone developed for FPC in 2001. Compiling under FPC 2.0.0, I'm getting the following error... wErrors0.pp(279,23) Error: Identifier not found "HeapError" From this code segment... procedure SetHeapErrorHandle; //=== // Defines a new HeapError handler, from this library. const fFirst : boolean = TRUE; // security, such that entering a second time is harmless begin if (not fFirst) then exit; fFirst:=FALSE; // the next time, will exit immediatly // Memorises the original Heap error handler glpfHeapErrorHandler:=HeapError; // defines the address of the new Heap Error handler. HeapError:=HeapErrorHandle; end; // SetHeapErrorHandle Section 8.4.2 of the prog.pdf doc "The Heap Grows", suggests that HeapError is a pointer that should be available for reference. Any suggestions would be appreciated. Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Windows Type LPARAM, WPARAM
Hi, I've been working with FPC 2.0.0 and Dev-Pas for some GUI efforts and another programmer pointed out an interesting thing, regarding the LPARAM and WPARAM types. I hope I'm not kicking up old dust, but for the sake of clarification if we may... The Microsoft architecture affiliates these two keywords as "Types", based upon case sensitivity, among the variouse usage they apply from a C perspectieve, where in Pascal, case is insensitive. In Dev-Pas' gui template, they assign these same words as follows... //- function WindowProc(Window: HWnd; AMessage, WParam, LParam: Longint): Longint; stdcall; export; LParam becomes Longint, but it is a TYPE actually. Without case sensitivity in Pascal, these same words can become declared variables as above, which leads to ambiguous code. //-- Consider the useage otherwise as ... function WindowProc(Window: HWnd; AMessage: UINT; WParam : WPARAM; LParam: LPARAM): LRESULT; stdcall; export; In hopes of avoiding a discussion on the merits of case-sensitivity in compiler design... Is there any way to switch on case sensitivity or otherwise a switch to have references become reserved words, such that their case insensitive nature can be raised as an error in the above cases? LPARAM AND WPARAM are consistently present in most windows usage. i.e. LParam: Longint > would raise an error for reserved word. LParam:LPARAM >would raise an error as a redundant cast xxx:Lparm would cast xxx to any case manner of Lparam/Wparam I suppose that there are a number of cased words in Windows that make the consideration impractical overall, but is this strictly a manner of managment on the programmers behalf, to watch declarations and scope closely, or could it ever be managed as a switched option? Thanks in advance, Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extended float to single and pchar types
Please ignore this. It is an FPC mailing list error, repeated from August
- Original Message -
From: "Urbansound" <[EMAIL PROTECTED]>
To:
Cc: "Matt Emson" <[EMAIL PROTECTED]>
Sent: Tuesday, August 02, 2005 1:41 PM
Subject: Re: [fpc-pascal] Extended float to single and pchar types
Thanks Matt.
See replies within the body please.
- Original Message -
From: "Matt Emson" <[EMAIL PROTECTED]>
To: "Urbansound" <[EMAIL PROTECTED]>; "FPC-Pascal users
discussions"
Sent: Tuesday, August 02, 2005 11:26 AM
Subject: Re: [fpc-pascal] Extended float to single and pchar types
Hi,
I have a stdcall reference to a c based dll. called target.dll
In c the setup is ...
Are you sure it is stdcall? Quite often it's the calling convention that
messes up the calling of a C DLL. Could it be safecall or cdecl? Which
compiler made the DLL?
Tried all three and results are the same always, (which I find odd,
considering mangling)
float Get_l1_BidPriceSingle(void* p);
The Pascal reference is...
function Get_l1_BidPrice(p : pointer) : single;
stdcall; external 'target.dll' name 'Get_l1_BidPrice';
Which all looks okay.
The end result is to allow a usage in win32 as ...
SendMessage(listbox, LB_ADDSTRING, 0, longint(Pchar(s)));
Hmmm.. this is not a good idea if 's' is of type string. If 's' is a
string
(AnsiString or whatever) you should probably call SetLength on it, and
I'd
also advise passing a pointer to the first char too, rather relying on
the
cast.
E.g.
s := 'Test data';
SetLength(s, Length(s));
SendMessage(listbox, LB_ADDSTRING, 0, longint(@(s[1])));
Working only by virtue of the non error checking method using
Str(bid_price:5:3,s);
See example at bottom.
That probably has more chance of working, but still assumes you are not
crossing process boundaries. If threads are involved, it's not going to
work.
Single thread, confirmed
The c reference is a 'Single' float, but each time I make refernece to
data
conversion, errors tell me that the reference to the call is returning a
10
bit "Extended" float which fails, appearing to be a default autotype
conversions to an extended 10 byte float, in fpc.
If it is a "reference", it should probably be a pointer. Is the C
function
really returning the resultant by value, or by reference?
Converted data as an "Ansistring" seems to fail any type of conversion,
as
a
runtime 207 crash.
Convert how? FloatToStr should handle any floating point type.
Apparently that is a problem when the float is in a callback.
e.g.
var
f: single;
d: double;
e: extended;
begin
f := 10.01;
d := 10.01;
e := 10.01;
messagebox(0, PChar(FloatToStr( .. ), 0); // replace '..' with f, d or e
end;
Crashes when incorporated into the callback.
If I store Str conversions to a "shortstring", I can format the fp and
convert it to a fixed decimal rounded output, xxx.yyy, but using
length()
direct or pointer access, still pulls the 0 byte and extra characters of
the
string into any other converted output, requiring array managment and
parsing.
var
s: string;
f: single;
begin
f := 123.45678; //this will round
s := format('%3.3f', [f]); //think sprintf
end;
Crashes same when f holds the value returned in the callback.
Is there a way to take an "extended" FP and covert it ultimately to a
Pchar
that would allow messaging to win32 list boxes or similar to a litteral
equivelent behaviour, without having to run through all the symantics of
array management?
OR
Can one circumvent the auto-typing to extended, so that single or double
would behave to conversion methods like FloatToStr() that I could then
type
over to pchar and serve the same purpose?
Surely you could just use an extended and then cast it? So long as it is
possible to store the value in the variable you wish to, it'll work.
Clearly I'm not yet comfortable with string manipulation in Pascal, so
an
example would go a long way toward getting me to where I can do the work
myself.
Well, it's an awful lot simpler that C until you have to interact with C
API
calls!!
M
Any ansistring causes a hard crash.
Below will run without crashing, but again the string length is even cast
at
9, the max expected and equal white space being seed to the string first.
You can see the image "output.jpg" attached, showing the residual string
data, right of the values. These are stock market symbols and their
related
prices being quoted, which are the content coming back from the live API.
Type shortstring = string[9];
var
bid_price : extended; //or double, or single = same result
s : shortstring;
begin
SendMessage(listbox, LB_ADDSTRING, 0,
longint(Get_secsym(quote)));
// quote data may range nn.nnn to n.n
Re: [fpc-pascal] Windows Type LPARAM, WPARAM
Please ignore this. FPC has generated this as an error. This is an old discussion from August - Original Message - From: Urbansound To: fpc-pascal@lists.freepascal.org Sent: Tuesday, August 16, 2005 9:25 PM Subject: [fpc-pascal] Windows Type LPARAM, WPARAM Hi, I've been working with FPC 2.0.0 and Dev-Pas for some GUI efforts and another programmer pointed out an interesting thing, regarding the LPARAM and WPARAM types. I hope I'm not kicking up old dust, but for the sake of clarification if we may... The Microsoft architecture affiliates these two keywords as "Types", based upon case sensitivity, among the variouse usage they apply from a C perspectieve, where in Pascal, case is insensitive. In Dev-Pas' gui template, they assign these same words as follows... //- function WindowProc(Window: HWnd; AMessage, WParam, LParam: Longint): Longint; stdcall; export; LParam becomes Longint, but it is a TYPE actually. Without case sensitivity in Pascal, these same words can become declared variables as above, which leads to ambiguous code. //-- Consider the useage otherwise as ... function WindowProc(Window: HWnd; AMessage: UINT; WParam : WPARAM; LParam: LPARAM): LRESULT; stdcall; export; In hopes of avoiding a discussion on the merits of case-sensitivity in compiler design... Is there any way to switch on case sensitivity or otherwise a switch to have references become reserved words, such that their case insensitive nature can be raised as an error in the above cases? LPARAM AND WPARAM are consistently present in most windows usage. i.e. LParam: Longint > would raise an error for reserved word. LParam:LPARAM >would raise an error as a redundant cast xxx:Lparm would cast xxx to any case manner of Lparam/Wparam I suppose that there are a number of cased words in Windows that make the consideration impractical overall, but is this strictly a manner of managment on the programmers behalf, to watch declarations and scope closely, or could it ever be managed as a switched option? Thanks in advance, Mike ___fpc-pascal maillist - fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
