Hi
Where can I get some examples on how to use the Windows unit. I want to perform some simple automation on Windows using fpc but don't know where to begin.
Thanks.
Paschal Mushubi

Mailing lists / fpc-pascal / 2001-08
5 messages · 3 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Hi
Where can I get some examples on how to use the Windows unit. I want to perform some simple automation on Windows using fpc but don't know where to begin.
Thanks.
Paschal Mushubi
Quoting "Mushubi, Paschal" :
Hi Where can I get some examples on how to use the Windows unit.
You'd be writing in plain windows API. There are few resources on the net in Pascal. I have a few bits and pieces, nothing I could give you easily without tonnes of explanation.
I want to perform some simple automation on Windows using fpc but don't know where to begin.
I don't think you can do automation with FPC yet?! Not OLE Automation, which is kind of what you imply.
If it's win 32 API, look arround on the net.. you'll find a lot in Turbo Pascal sites, and also a lot in C.
At 8/15/01 06:07 PM, you wrote:
Dear Full_Name (?),
I don't think you can do automation with FPC yet?! Not OLE Automation,
which
is kind of what you imply.
I do it regularly, although I had spurious errors and crashes and I temporarily reverted to C with an ongoing project. You have to write your own calling mechanism but then you can use it freely. Basically, you create a helper routine that fills the appropriate data structures with your parameters then call the necessary Windows routines. The original C way of doing it is the same, you can simply translate it to Pascal. FPC doesn't yet have Unicode string support but this only causes small and surmountable problems (the best solution is found was to use the Windows Unicode string functions instead of the FPC RTL ones).
Regards,
Gabor DEAK JAHN
------------------------------------------------------------------- Gabor DEAK JAHN -- Budapest, Hungary.
WWW: www.tramontana.co.hu
E-mail:
Quoting Gabor DEAK JAHN :
At 8/15/01 06:07 PM, you wrote: Dear Full_Name (?),
My isp has an web front end for email.. it doesn't allow you to change the name !! :( I've grown to accept it...
I do it regularly, although I had spurious errors and crashes and I temporarily reverted to C with an ongoing project. You have to write your own calling mechanism ... <snip>
You can stop at this point ;) FPC may be 'able' to OLE automate in this way, but it's a 'hack', 'kludge' etc, in-so-much-as if you do it in Delphi, you don't have to do any of this. I doubt that this answer was what the original poster was after. It's only a solution if you truely understand how the whole com/ole mechanism works to quite a low level. I would *not* call it 'supporting' OLE Automation. After all I could instanciate and use C++ classes in FPC - if I hand code the calls in assembler. I wouldn't call this 'supporting' C++ by a long chalk.
At 8/16/01 01:52 PM, you wrote:
Dear Friend,
My isp has a web front end for email.. it doesn't allow you to change the name !! :( I've grown to accept it...
Actually, a viable solution would be then to sign your letters with your name, then we could know who we are responding to... :-))
poster was after. It's only a solution if you truely understand how the
whole
com/ole mechanism works to quite a low level. I would *not* call it 'supporting' OLE Automation. After all I could instanciate and use C++
Partly you're right, a more elegant solution would be much better, although you can delegate most of the functionality into a separate unit (I sent such a unit to Michael in the meantime). If you use a unit like that, maybe coming bundled with the compiler later, you don't have to worry about the low level details yourself.
And you should also note that all OLE methods have an associated dispatch ID (a unique number) and should be invoked using this ID. There is, however, two ways to achieve this: either you use the string name of the method and query the actual ID from the COM interface every time you call that particular function or you create your wrapper procedures and functions beforehand, hardwire the IDs and the parameter passing and then use these wrapper functions from your program (these routines already have nothing COM-like about them, you can call them just like any other proc/func in your program).
The second solution is much more efficient, doing away with an extra call and some string manipulation for each and every call you make. However, a universally automatic solution like in Visual Basic cannot use this second approach, only the first one. Thus, if you prefer that kind of a solution, you might spare some work but will end up with a much less efficient solution.
Actually, using my unit as it is know requires of you nothing more than to write exactly those wrapper procedures and functions which make up this second approach. And you would need to write them anyway, for the sake of efficiency, even if FPC offered the most automatic integration with OLE that can be dreamt of.
Bye,
Gábor
------------------------------------------------------------------- Gabor DEAK JAHN -- Budapest, Hungary.
E-mail: