Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

What I need to do is be able to read some 5v TTL Inputs in and write some 5v
TTL outputs out.  The parallel port always worked when my program was a DOS
program.. it was so simple, just do Port[$378]:= data to set the bits on the
port  or data:=port[$378] to read some bits from the port.   I'm not opposed
to some hardware other than a parallel port if it will be able to interface
with freepascal easily, if anyone can make a recommendation.   Serial ports
won't work because they are not made to just read and write bits like the
parallel port and they are not TTL voltage levels.

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Marc Santhoff
Sent: Wednesday, July 20, 2016 11:29 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

On Fr, 2016-07-15 at 14:59 -0700, Zaaphod wrote:
> I am trying to get access to the parallel port with Free Pascal.  
> 
> I'm trying to use this version of inpout32 (x64) 
> http://www.highrez.co.uk/downloads/inpout32/
> 
> Here's my program:
> http://pastebin.com/facf6EFc
> 
> Here's my Unit:
> http://pastebin.com/XR0aYUPR
> 
> When I try to run it, I get a windows message The application was 
> unable to start correctly (0xc07b). click ok to close the application.

You could search Microsofts web site to decode this error.

> then  I get Exitcode 123 in the Free Pascal IDE.  123 is decimal of 7b.
> 
> Does anyone know how to get this to work?   reading and writing the
parallel
> port used to be so easy, now it's extremely confusing, thanks windows!

Didn't test, but as a remark: parallel port is dead and it has been a
constant source of problems. First the access rights problems you know of.
Second it has no fixed timing, so you're in trouble when e.g.
flashing a microcontroller works on one machine and refuses to on another
one. Third it is not electrically protected, if you fry it, the mainboard is
dead by chance or you have to insert an extension board - which is hard to
find nowadays, too.

Depending on your needs I'd suggest using a USB-to-serial-Adapter or
similar. They are cheap and well supported (e.g. using CP2102). As an
alternative FTDI has some nice USB-to-anything (including parallel) chips
and they sell modules with mil spacing pins for easy breadboarding.

HTH somehow,
Marc


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

Thank you!  I was indeed trying to use the 64bit DLL.. I mistakenly thought
you were supposed to use the version of the operating system, not the
program.

I have absolutely zero experience with windows programs.   I am able to run
my program now, but still not working exactly as I want it to work.. but I
think I might need to set my port to the right mode.. so I'll see if that
works.



-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Marc Santhoff
Sent: Friday, July 22, 2016 10:56 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows
> > When I try to run it, I get a windows message The application was
> unable to
> > start correctly (0xc07b). click ok to close the application.
> 
> You could search Microsofts web site to decode this error. 

Or use a search engine:

http://www.techanges.com/fix-error-0xc7b/
http://stackoverflow.com/questions/10492037/the-application-was-unable-to-st
art-correctly-0xc07b

Looks like you are using a 32 Bit version on 64 bit or the like. The
original site tells about similar error:

http://www.highrez.co.uk/downloads/inpout32/

Look at the update history...


Marc

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

I like the looks of that Velleman K8055,  that would do the job for me if I
can get it to work.   I would actually prefer a linux port of my program
however I keep hitting a roadblock when I try to use the graph unit.  My
program used the turbo pascal graph unit exclusively for it's user interface
and I'm trying to avoid re-writing the entire thing.  It works fine in
windows, but when I try to run it on linux I can't get it to compile, it
can't find the graph unit.  I may have some directories set wrong or
something, I'm not sure, but that's what's holding me up on a linux port.


-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Mark Morgan
Lloyd
Sent: Friday, July 22, 2016 10:19 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

James Richters wrote:
> What I need to do is be able to read some 5v TTL Inputs in and write 
> some 5v TTL outputs out.  The parallel port always worked when my 
> program was a DOS program.. it was so simple, just do Port[$378]:= data to
set the bits on the
> port  or data:=port[$378] to read some bits from the port.   I'm not
opposed
> to some hardware other than a parallel port if it will be able to
interface
> with freepascal easily, if anyone can make a recommendation.   Serial
ports
> won't work because they are not made to just read and write bits like 
> the parallel port and they are not TTL voltage levels.

Something like a Velleman K8055, which I've talked to using libusb on Linux.
Or an Arduino with appropriate firmware. Or go the whole hog and port the
program onto a Raspberry Pi: Bo's doing something like you're asking.

Any of those have the advantage that the electronics can be positioned to
minimise the signal run carrying TTL. Long printer cables are generally bad
news.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Linux Port help

[James Richters]

I'm a newbie trying to port an old turbo pascal program to FreePascal in
linux.   My reasons for doing this is old Pentium 233 motherboards are
getting harder to keep running and I need be running on more modern
hardware..  It's a massive program and I just don't have time to re-write
the whole thing, that's why freepascal seems like a good solution.  I have
it working fairly well on windows, but I'm trying to get away from windows,
and get it working on linux instead.   I've managed to get free pascal
installed on an Ubuntu x64 virtualbox VM and I can run the IDE, but I'm
having difficulty getting it to work.  I have several issues I just don't
know how to solve

1.  graph unit issues.In my windows port I'm able to use graph unit, in
linux there is no graph unit in the x86_64-linux folder.  It does exist in
i386-linux, but I can't seem to compile my program for 386.  In the windows
version I have an option to use 80386, in linux I do not.   I have tried to
use the other graphic units found in graph under x86_64 linux.  I was able
to successfully compile with ptcgraph, but everything is blue, I figure it
is using more colors than my old 16, so I changed a few colors to larger
numbers and sure enough I can get other colors... so I could do global
searches and replaces to solve the color issue.. but I have other issues
with ptcgraph and/or linux.
If I try to use ggigraph, I cannot even compile it.  It says "Error while
linking" and it references the END. Line at the end of my main program.. I
don't know why, there is nothing wrong with that line and it compiles with
ptcgraph just fine.

2. I can't get my fonts to work with ptcgraph.  I was using the turbo pascal
graphic fonts, I was able to get them working in windows, but not in the
linux version.  I'm not sure if it's an issue with ptcgraph or linux or how
to even start to figure out the problem.

3. with ptcgraph, I have no control of the keyboard.   When I run from the
compiler, I must pop up the terminal window on top of my graphics window to
be able to use the keyboard, however if I try to run the compiled program on
it's own, I don't have a terminal window.. and I just have no control over
the program.. I have my graphic screen, but it ignores the keyboard, and I
can't do anything with it.  The windows version also has the Dos window, but
it allows it to remain behind the graphic window and my keyboard still
works.

4. not full screen.  For some reason I can't get it to be full screen in
linux at all.. Its always in a window.  The windows version is ALMOST full
screen, I would like to get rid of the windows bar across the top and make
it truly full screen.  I don't need a way to minimize it or to use any
windows controls, when I'm done with it I can just close it and be back in
windows.  

Any suggestions on how to either use the original 'graph' unit or how to
change to something else and retain functionality?  All I want to do is make
my program look and operate the way it did on DOS with turbo pascal.  I
don't want to redesign the entire thing.  The windows version is close but
as I mentioned I would love to get rid of the windows bar across the top of
the screen and make it truly full screen. 





___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Linux Port help

[James Richters]

Thank you for the F11 suggestion.. F11 does make the IDE window full screen,
Thanks!! That's very helpful.  My program however does not respond to F11.
There is no way to resize the window, make it larger or smaller or full
screen, it's just a fixed size window.. this is the version using ptcgraph

Is there a way to get the linux text mode IDE to colorize things like the
windows text mode IDE?  Linux is just all yellow on light blue. The windows
one for example will show comments in grey  reserved words in white.. ect..
it makes it a lot easier to follow 

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Graeme
Geldenhuys
Sent: Friday, July 22, 2016 4:28 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Linux Port help

On 2016-07-22 20:59, James Richters wrote:
> 4. not full screen.  For some reason I can't get it to be full screen 
> in linux at all..

Press F11. That is a almost universal shortcut for any X11 desktop
environment and Window Manager to switch the active program to full screen.

If you are running the program in a Console login (ie: no X11 running), then
in should be fullscreen as standard.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

I'm trying to avoid custom hardware if possible.  I have always used
parallel ports and never had a problem with them until now.   I like the
idea of a parallel port because they are still built onto motherboards, and
there are also a TON of USB to parallel port adapters out there.   I'm
trying to keep this simple.

I put a repository of my test program here:
https://github.com/Zaaphod/FPC-Parallel-Port.  Perhaps someone can see what
I'm doing wrong.I'm reading 255s no matter what I do.I included my
old turbo pascal test program.  I would normally specify the port in hex
with a $ like this $378.  I could write to the port then read back what I
just wrote.. which is what I am trying to do now.. I don't have anything
hooked up to the port yet, I should be able to write to it and read it back.

I seem to be accessing the DLL correctly, because I tried it on a windows 7
computer and  IsInpOutDriverOpen was false, because I forgot to install the
driver, once I installed the driver IsInpOutDriverOpen is now true, so that
tells me I'm accessing the DLL and the DLL is confirming the driver is open.


-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Mark Morgan
Lloyd
Sent: Friday, July 22, 2016 5:39 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

James Richters wrote:

I was rather rushed earlier for reasons that would probably amuse but would
be vastly OT (shoving sheep around Sussex since we're shearing Saturday...).

> I like the looks of that Velleman K8055,  that would do the job for me if
I
> can get it to work.   I would actually prefer a linux port of my program

The Velleman boards usually come as kits, but they use PTH components and
are a doddle to assemble. My recollection is that the K8055 came with
something crude that allowed you to interface from e.g. Visual Basic,
however I found that somebody had reverse-engineered it and produced a
library (?) for Linux... I can't remember whether this was C or Pascal. I
used this with Lazarus (the IDE and class library that sits on top of FPC)
to produce something similar to Velleman's own demo app, you'd obviously be
welcome to this.

However in the general case I think it would be worth bearing in mind that
functionality of the Velleman board could fairly easily be implemented using
appropriate firmware on an Arduino, and this is likely to be more "future
proof" than a demo kit. But I don't have any ready URLs etc.

> however I keep hitting a roadblock when I try to use the graph unit.  
> My program used the turbo pascal graph unit exclusively for it's user 
> interface and I'm trying to avoid re-writing the entire thing.  It 
> works fine in windows, but when I try to run it on linux I can't get 
> it to compile, it can't find the graph unit.  I may have some 
> directories set wrong or something, I'm not sure, but that's what's
holding me up on a linux port.

Can't comment on that, but I see Graham's lending a hand. Particularly if
you're porting to Linux you do need to consider whether you're planning to
run in the context of a GUI or over SSH etc, what /exactly/ are you trying
to display and on what sort of system?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Linux Port help

[James Richters]

Yes, they are both 1.0.12 included with fpc 3.0.0   Here are screenshots:
https://github.com/Zaaphod/FPC-Parallel-Port/issues/1

I like the text ide because I understand it,  it's pretty much like the
Turbo Pascal ide.   I tried installing lazerus and I cannot even compile my
program with that... but it's not a windows program, it's a console
application, so that's probably why I couldn't get it to compile with
lazerus.

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Graeme
Geldenhuys
Sent: Friday, July 22, 2016 6:18 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Linux Port help

On 2016-07-22 21:38, James Richters wrote:
> Linux is just all yellow on light blue. The windows one for example 
> will show comments in grey  reserved words in white.. ect..
> it makes it a lot easier to follow

Are they the same versions of the IDE?  I don't really use the Text IDE, but
I can say that the FreeBSD version behaves like the Linux version you
describe the old Turbo Pascal IDE look and feel.

I've never tried the Text IDE under Windows.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Linux Port help

[James Richters]

I checked and syntax highlight was already checked.. I did figure it out
though.. all my pascal files were named with a .PAS extension and I keep
forgetting that linux is extremely case sensitive with everything.. I saved
one with a .pas extention,  closed it then opened it and now that one file
has the highlight, the others do not.. easy enough to fix that though.

Thank you for the help and suggestions to tweak the colors!   I would have
never figured that out!  Nice I can customize it too.   I can't figure out
how to do that with windows.   I would like to get a black background
instead of blue.  

Thanks also for the suggestion of MSEIde  I will check it out!


-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Graeme
Geldenhuys
Sent: Friday, July 22, 2016 7:41 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Linux Port help

On 2016-07-22 23:33, James Richters wrote:
> Here are screenshots:
> https://github.com/Zaaphod/FPC-Parallel-Port/issues/1

I just checked. My FreeBSD version looks like the Windows screenshot.

Also under Linux, load the IDE, then go to Options -> Environment -> Editor.
Then under "Editor options" make sure "Syntax highlighting" is checked. If I
uncheck that and open a new *.pas file, then mine is all blue and yellow
text.

Something else to tweak. If you prefer the darker blue (Windows
screenshot) instead of the lighter blue (Linux screenshot). Those colors are
affected by your terminal program's console theme. eg: I use Mate Terminal
here. Go to Edit -> Profile Preferences -> Colours. Change the Palette
scheme to "Linux console" or "Rxvt". Those are my preferences.
Some Linux systems default that to "Tango" which are much lighter colours.


> I like the text ide because I understand it,  it's pretty much like 
> the Turbo Pascal ide.

I fully understand. Sometimes I use the Text IDE too, to get rid of all
clutter and distractions seen so often in other IDE's or text editors.
But I forgot all the keyboard shortcuts, then I get frustrated with it, and
switch back to Lazarus or MSEide. MSEide is also a very nice, flexible and
super fast IDE. They can all handle console programs without problems.

  MSEide
 https://sourceforge.net/projects/mseide-msegui/

You can download the IDE zip archive, unpack and run the binary. No need for
any installations.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

I have an update on this.   I found a demo program here:
http://www.highrez.co.uk/downloads/inpout32/   I was able to successfully
run the demo program and access my parallel port.  I could write to it and
read back what I just wrote accurately.  I wrote '123' decimal to it, then
tried to read it back with my freepacal program,  it read 255.. then I tried
to read it back with the demo program, it was still 123.  So this proves
that my parallel port is working and that it works with this DLL.  The
question is, why can't I access it with my freepascal program?  

I am wondering if it has something to do with my variable declarations.  I
used shortint for the port address but I wonder If it should be something
else.. the c++ example used smallint, but maybe that's not the same thing?
I randomly tried some other types but still no luck.  There has to be some
simple reason why I can't get this to work... any ideas?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

I get 
Error: Calling convection doesn't match forward
Error: Found Declaration: IsInpOutDriverOpen:Boolean;

Do I need to specify the functions differently in the interface section?
Thanks for the help


-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Marc Santhoff
Sent: Saturday, July 23, 2016 1:09 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

On Sa, 2016-07-23 at 05:55 +0200, Marc Santhoff wrote:
> On Fr, 2016-07-22 at 18:20 -0400, James Richters wrote:
> > I'm trying to avoid custom hardware if possible.  I have always used
> > parallel ports and never had a problem with them until now.   I like the
> > idea of a parallel port because they are still built onto motherboards,
and
> > there are also a TON of USB to parallel port adapters out there.   I'm
> > trying to keep this simple.
> > 
> > I put a repository of my test program here:
> > https://github.com/Zaaphod/FPC-Parallel-Port.  Perhaps someone can see
what
> > I'm doing wrong.I'm reading 255s no matter what I do.I included
my
> > old turbo pascal test program.  I would normally specify the port in 
> > hex with a $ like this $378.  I could write to the port then read 
> > back what I just wrote.. which is what I am trying to do now.. I 
> > don't have anything hooked up to the port yet, I should be able to write
to it and read it back.
> > 
> > I seem to be accessing the DLL correctly, because I tried it on a 
> > windows 7 computer and  IsInpOutDriverOpen was false, because I 
> > forgot to install the driver, once I installed the driver 
> > IsInpOutDriverOpen is now true, so that tells me I'm accessing the DLL
and the DLL is confirming the driver is open.
> 
> >From what I know, although it may be a bit outdated, on windows 
> >external
> functions have to be declared 'cdecl'. Which isn't so in the library 
> port to pascal.
> 
> One example:
> 
>   implementation
>   Function IsInpOutDriverOpen; external 'inpout32.DLL';
> 
> would then be:
> 
>   implementation
>   Function IsInpOutDriverOpen; cdecl; external 'inpout32.DLL';

No, sorry. It has to be the other way round:

  Function IsInpOutDriverOpen; {$ifndef Win32}cdecl{$else}stdcall{$endif};
external 'inpout32.DLL';

I didn't recognize that it is  $ifndef, not $ifdef.

Marc


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

Thank you for getting me on the right track with this Marc,  I have it
working now!
Here is a link I found that explains it: 
http://www.freepascal.org/docs-html/ref/refsu72.html

I would have never thought of that!  

I posted the fixed program on github here if anyone is interested:
https://github.com/Zaaphod/FPC-Parallel-Port

I tested it the Inp32 and Out32 functions and they are now working!  
Thank you everyone very much for the help with this!

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Marc Santhoff
Sent: Saturday, July 23, 2016 1:09 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

On Sa, 2016-07-23 at 05:55 +0200, Marc Santhoff wrote:
> On Fr, 2016-07-22 at 18:20 -0400, James Richters wrote:
> > I'm trying to avoid custom hardware if possible.  I have always used
> > parallel ports and never had a problem with them until now.   I like the
> > idea of a parallel port because they are still built onto motherboards,
and
> > there are also a TON of USB to parallel port adapters out there.   I'm
> > trying to keep this simple.
> > 
> > I put a repository of my test program here:
> > https://github.com/Zaaphod/FPC-Parallel-Port.  Perhaps someone can see
what
> > I'm doing wrong.I'm reading 255s no matter what I do.I included
my
> > old turbo pascal test program.  I would normally specify the port in 
> > hex with a $ like this $378.  I could write to the port then read 
> > back what I just wrote.. which is what I am trying to do now.. I 
> > don't have anything hooked up to the port yet, I should be able to write
to it and read it back.
> > 
> > I seem to be accessing the DLL correctly, because I tried it on a 
> > windows 7 computer and  IsInpOutDriverOpen was false, because I 
> > forgot to install the driver, once I installed the driver 
> > IsInpOutDriverOpen is now true, so that tells me I'm accessing the DLL
and the DLL is confirming the driver is open.
> 
> >From what I know, although it may be a bit outdated, on windows 
> >external
> functions have to be declared 'cdecl'. Which isn't so in the library 
> port to pascal.
> 
> One example:
> 
>   implementation
>   Function IsInpOutDriverOpen; external 'inpout32.DLL';
> 
> would then be:
> 
>   implementation
>   Function IsInpOutDriverOpen; cdecl; external 'inpout32.DLL';

No, sorry. It has to be the other way round:

  Function IsInpOutDriverOpen; {$ifndef Win32}cdecl{$else}stdcall{$endif};
external 'inpout32.DLL';

I didn't recognize that it is  $ifndef, not $ifdef.

Marc


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

Bo, 
I also have a raspberry pi project..  I got a hifi-berry card for it and it
is streaming audio to a central audio system, I'm using VLC media player and
an app on my cell phone to control it,  I have not made use of the GPIO on
them yet, but I would really like to learn how this can be accomplished with
FPC, since I am more familiar with pascal than any other language, it would
be great to learn how to do this!  I have a particular application in mind.
I have a relay board that will turn relays on and off with TTL level
signals, what I wish to do is have a remote way to turn certain amplifiers
on and off.   There are 24 amplifiers going to 44 speakers (4 are
subwoffers) in and around my house, sometimes I'll want just downstairs and
outside amps on, other times I'll want just one room on, or all amps on
etc.The amps are all in my crawlspace under the first floor, and that's
where the raspberry pi is.  I also have some volume control chips that are
controlled by clocking data into them, I could chain them all together and
be able to control all of them with just one clock and one data bit.   
Any advice on how to get started on controlling GPIO with a raspberry pi
with FPC would be greatly appreciated!

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Bo Berglund
Sent: Sunday, July 24, 2016 2:22 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

On Fri, 22 Jul 2016 14:19:20 +, Mark Morgan Lloyd
 wrote:

>Or go the whole hog and
>port the program onto a Raspberry Pi: Bo's doing something like you're 
>asking.

Yes, indeed! I now have something like 7-8 operational RPi units for
different purposes and in several places I have used the GPIO pins to
control and read back digital stuff from FPC programs. Very convenient.

Last I did was to attach a 4-way relay board to a RPi and put a smapp FPC
command line program on it, which gets called from a PHP script on the
Apache webserver on the Pi.
Now I have a webpage, with which I can switch on/off the relays with in
order to control the operational state of some measuring equipment sitting
half way across the workd!

You could do a LOT with FPC and a Raspberry Pi!

Examples:
The Pi also runs an OpenVPN server so I can access it with PuTTY and/or
TightVNC to program it if I need to.

My Pi also has a port mapping utility which makes it possible for me to
remotely access a WiFi network device on a WiFi access point close to the
RPi again from a long distance away. THis was created with FPC and Indy10 on
the RPi.


>Any of those have the advantage that the electronics can be positioned 
>to minimise the signal run carrying TTL. Long printer cables are 
>generally bad news.

15 cm wires to the relay board...


--
Bo Berglund
Developer in Sweden

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Textmode IDE splitscreen?

[James Richters]

Is there a way to get the textmode IDE to do splitscreen the way Turbo
Pascal used to if you had both a color and monochrome monitor?  It was very
handy to trace through the source code on the monochrome monitor and watch
it execute on the other one.. It prevented all the screen flashing when it
had to output something to the screen as you traced through the program.
I've been doing this on windows with TurboPascal with a customized version
of DOSBOX that would show the monochrome monitor in a separate window from
the color monitor.  Any suggestions for getting two windows with Free Pascal
textmode IDE?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Textmode IDE splitscreen?

[James Richters]

The TurboPascal version used to write to B800-B7FF for the monochrome
monitor and A000-AFFF for the color monitor, the IDE was always on
monochrome and the program executing was always on color... that's how it
worked,  but all that is really needed to help improve debugging with
freepascal is to get the "User Screen ALT-F5" to be in a different window so
you don't need to switch windows back and forth when trying to trace through
a program or watch variables.   It is updating both screens now, just you
can only see one at a time.   I have no idea how to get a second window
though, since it's running in a command prompt.  DOSBox already had 2
windows, someone made a patch to display the monochrome addresses in the
status window.. it was a little quirky but it worked.Maybe there needs
to be another program running in another DOS window and the two programs
have some way to send the screen to the second window and receive keystrokes
back.


-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Pierre Free
Pascal
Sent: Monday, July 25, 2016 5:21 AM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] Textmode IDE splitscreen?

  Hello,

  The TextMode IDE is based on the package FV short for Free Vision, which
tries to follow TurboVision interface.

  But there is nothing inside that package that deals with dual monitor, so
I don't think this is possible with the current TextMode IDE.

  

  If you are only looking for a solution for the go32v2 IDE, what Dos Video
mode does your split screen correspond to?

  The switching between User and IDE is done mainly in ide/fpusrscr.pas
unit.
  Look for TDosVideoInfo record and TDosScreen object, and try to look into
the code how the support for your special split mode could be integrated.

  If the two screens have different Segments associated (look for VSeg local
variables in SaveIDEScreen, SaveConsoleScreen, SwitchToConsoleScreen and
SwitchBackToIDEScreen methods), it might be possible to  the code quite
easily.

In the hope it could lead to an improvement of the go32v2 IDE,

Pierre Muller



> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal- 
> boun...@lists.freepascal.org] De la part de James Richters Envoyé : 
> dimanche 24 juillet 2016 23:57 À : 'FPC-Pascal users discussions'
> Objet : [fpc-pascal] Textmode IDE splitscreen?
> 
> Is there a way to get the textmode IDE to do splitscreen the way Turbo 
> Pascal used to if you had both a color and monochrome monitor?  It was 
> very handy to trace through the source code on the monochrome monitor 
> and watch it execute on the other one.. It prevented all the screen 
> flashing when it had to output something to the screen as you traced 
> through the program.
> I've been doing this on windows with TurboPascal with a customized 
> version of DOSBOX that would show the monochrome monitor in a separate 
> window from the color monitor.  Any suggestions for getting two 
> windows with Free Pascal textmode IDE?
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Textmode IDE splitscreen?

[James Richters]

I stand corrected, Now that I think of it, I also had the IDE on the color
screen and program executing on monochrome. however most of my programs used
the turbo pascal graph unit so my executing program needed the VGA screen...
I guess I got used to it being set up like that. 
Thanks for correcting me.

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Ralf Quint
Sent: Monday, July 25, 2016 8:32 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Textmode IDE splitscreen?

On 7/25/2016 5:06 AM, James Richters wrote:
> The TurboPascal version used to write to B800-B7FF for the monochrome 
> monitor and A000-AFFF for the color monitor, the IDE was always on 
> monochrome and the program executing was always on color... that's how 
> it worked,
No, it didn't.

The monochrome screen RAM is at segment address $B000 and while a whole 32KB
is reserved ($-B7FF), only the first 4KB are in fact used. (80x25
characters, 2 bytes per character=4000 bytes) The Hercules graphics card did
use the whole 32KB when in graphics mode.

The default page for color text mode (mode 3) starts at $B800, is also 4KB
and a total of 8 pages are available up to $BFFF, though an original CGA
card had  only 16KB and hence only the first 4 pages are available.

And it was a choice which screen appears on which monitor, selectable as a
parameter upon start of the IDE. I in fact used to run most of the time with
the IDE on the color screen and the program output on the monochrome screen,
unless I would explicitly test a program with color screen features.

$A000 is the start of the EGA/VGA graphics screen, not a text screen segment
address...

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Textmode IDE splitscreen?

[James Richters]

>If you are using Windows, you can compile the IDE in FPC trunk with gdb/mi
support, 
>which works by opening your program in a new console window, so it gets the
effect
>you want already under Windows. Lazarus also does the same thing, if you
don't mind 
>using a newer IDE.

I'm using Windows,  Can you explain exactly what you mean by "compile the
IDE in FPC trunk with gdb/mi support" to be honest that went right over my
head.Are you talking about an option inside the existing IDE I should
turn on that changes how my program compiles so it gets a separate window,
or that I somehow recompile the IDE itself with some option so that it
always executes my program in a new window? 

I've tried Lazarus, for some reason I can't even get my program to compile
with Lazarus, I get pages of errors.  Maybe I just don't know how to get
Lazarus into Turbo Pascal Compatible mode..   

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Textmode IDE splitscreen?

[James Richters]

Thanks for the info. I will give it a try.   I was doing some DOS function 
calls, inline assembly,  and direct hardware access with PORT[ ] commands.  I 
just went though and commented out everything that wouldn’t work so it would 
compile and now I’m finding ways to make those things work.  I have the bulk of 
it working great, still a few minor details to work out, but it’s a LOT less 
work than a complete rewrite!

 

From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Sven Barth
Sent: Monday, July 25, 2016 6:25 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Textmode IDE splitscreen?

 

Am 25.07.2016 22:52 schrieb "James Richters" mailto:ja...@productionautomation.net> >:
> I've tried Lazarus, for some reason I can't even get my program to compile
> with Lazarus, I get pages of errors.  Maybe I just don't know how to get
> Lazarus into Turbo Pascal Compatible mode..

In your project's settings there is somewhere among the compiler options 
(sorry, I don't have it on front of me right now) a combobox that allows you to 
select the default mode. This is normally "ObjFPC", but you want to switch that 
to "TP".
Alternatively you can add "{$mode tp}" at the top of each of your units.

Please keep in mind though that quite some DOS tricks won't work when compiled 
on Windows (due to virtual memory, different API, etc.). Though as long as your 
program does not do any strange hardware accesses you should be fine.

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Microsecond Delay Suggestions?

[James Richters]

Any Suggestions for a microsecond delay?  I had a scheme in my old dos program 
where I would run a massive loop at the beginning of my program and time it 
with DOS 55mS ticks, then do the math and figure out how many times I needed to 
loop for a given delay.. worked great on DOS with nothing else using the 
processor, but completely invalid for windows.  I see delay() and sleep() but 
they are both only good down to 1mS and I would like to go down to 1uS.  Any 
suggestions on how to do this on windows with a console application? 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Microsecond Delay Suggestions?

[James Richters]

I don’t need a 55mS tick, there was a DOS timer that ticked every 55mS, which I 
used to calibrate a delayloop.. however I can’t use any of that on windows, I 
can’t even make the DOS function call, and even if I had a way to calibrate my 
delay loop, it would be meaningless because I have to share the processor with 
windows, so creating a delay by just looping a lot doesn’t work at all in 
windows… depending on what else is running I would get totally different time 
delays out of the loop.

 

What I need is a timer that I can specify in microseconds, a millisecond is too 
long.   I am using it for timing to read in a string on a serial connection.  
My fastest baudrate is 25, so at that rate I would need to delay only 36 
microseconds.  So I can’t use sleep () or delay () because they only go down to 
1mS and that’s too slow.

 

From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Dmitry Boyarintsev
Sent: Tuesday, July 26, 2016 11:19 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Microsecond Delay Suggestions?

 

On Tue, Jul 26, 2016 at 11:16 AM, James Richters 
mailto:ja...@productionautomation.net> > wrote:

Any suggestions on how to do this on windows with a console application?


I don't have an answer, but I'm wondering what kind of task is that? 
Why do you need this 55mS tick?

thanks,

Dmitry

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Microsecond Delay Suggestions?

[James Richters]

That looks great.   I’ll give it a try!  Thank you very much for the suggestion 
and the example

 

From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Dmitry Boyarintsev
Sent: Tuesday, July 26, 2016 11:45 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Microsecond Delay Suggestions?

 

On Tue, Jul 26, 2016 at 11:21 AM, Dmitry Boyarintsev mailto:skalogryz.li...@gmail.com> > wrote:

Maybe you want to look into QueryPerformanceCounter.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx 

 

Here's an example:

{$mode objfpc}{$H+}

uses
  Windows;

const
  MSInSec = 1000;
  MCInSec = MSInSec * 1000;
  NSInSec = MCInSec * 1000;

function LargeLoop: Integer;
var
  i : integer;
begin
  Result:=0;
  for i:=0 to 1000 do
inc(Result);
   //or you can verify Sleep(milliseconds)
   //Sleep(100);
end;

var
  fr : TLargeInteger;
  ct : TLargeInteger;
  af : TLargeInteger;
  d  : double;
  diff : TLargeInteger;
begin
  QueryPerformanceFrequency(fr);
  writeln('Frequency: ' ,fr);
  d:=(1/fr) * NSInSec;
  writeln('Freq in Time: ', d:0:0, ' ns (roughly)');
  QueryPerformanceCounter(ct);
  LargeLoop;
  QueryPerformanceCounter(af);
  diff := af - ct;
  writeln('Loop:');
  writeln('  Ticks: ', diff);
  writeln('  Time:  ', ((diff/fr) * NSInSec):0:0,' ns' );
  writeln(' ', ((diff/fr) * MCInSec):0:6,' mcs' );
  writeln(' ', ((diff/fr) * MSInSec):0:6,' ms' );
end.

 

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Microsecond Delay Suggestions?

[James Richters]

I think there may be a solution with this performance counter for my purposes…  
here’s what I’m trying to accomplish:

 

I’m trying to read a string from a serial port until I get a linefeed, but I 
don’t want it to get stuck in an endless loop which could happen if:

A: nothing is ever received

B: garbage is being received due to bad connection or baudrate mismatch.. etc..

So I keep reading the port in a loop until

A:  I try 10 times and still get nothing

B:  I get the data I’m looking for ending with a #10 

C:  I get too much data, then I stop after 254 bytes, the response should never 
be that long, so I’ll flag that as garbage.

D: I try 1000 times and still do not have a #10 but I also do not have 254+ 
bytes

 

For fast baud rates, this works fine, but for slow baudrates, I reach 1000 
tries way before the string is finished, so I planned on putting in a delay 
calculated from the baudrate… however I think I can take a different approach 
here.  I don’t really care the exact amount of time between retries, I just 
want to try for a long enough length of total time before giving up, so I don’t 
get stuck in a loop.   Perhaps I can read   QueryPerformanceCounter(ct); during 
the loop and if it exceeds the set amount of time, then use that to end the 
loop and give up.   

 

Here’s my function as it is.. fyi, my entire project is in turbo pascal 
compatibility mode:

 

Function ReadSerial(SerPortNum:Byte):String;

Var

   Loopcount:Word;

   CharCount:Byte;

   InputString:String;

   InputLetter:Char;

Begin

   LoopCount:=0;

   CharCount:=0;

   InputString:='';

   repeat

  Status:= SerRead(SerialHandle[SerPortNum], Inputletter, 1);

  if (status > 0) {and ((InputLetter<>#10) AND (InputLetter<>#13))} then

   begin

  Inc(CharCount);

  case InputLetter of

  ' ':InputString:=InputString+'.';

  #10:InputString:=InputString+'#10';

  #13:InputString:=InputString+'#13';

  else

 InputString:=InputString+(InputLetter);

end;

 end;

  Inc(Loopcount);

  {need delay here for slow baud rates}

Until (InputLetter=#10) OR ((Loopcount>10) AND (InputString='')) OR 
(CharCount>254) OR (Loopcount>1000);

ReadSerial:=InputString;

end;

 

 

From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Dmitry Boyarintsev
Sent: Tuesday, July 26, 2016 1:05 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Microsecond Delay Suggestions?

 

On Tue, Jul 26, 2016 at 12:38 PM, James Richters 
mailto:ja...@productionautomation.net> > wrote:

What I need is a timer that I can specify in microseconds, a millisecond is too 
long.   I am using it for timing to read in a string on a serial connection.  
My fastest baudrate is 25, so at that rate I would need to delay only 36 
microseconds.  So I can’t use sleep () or delay () because they only go down to 
1mS and that’s too slow.

 

Here's an example of Sleep with microseconds that I came up with 


procedure SleepMcs(mcs: Int64);
var
  ct : TLargeInteger;
  fr : TLargeInteger;
  af  : TLargeInteger;
  trg : TLargeInteger;
const
  NanoInMicro = 1000;
begin
  QueryPerformanceCounter(ct);
  QueryPerformanceFrequency(fr);
  trg:=round(mcs * NanoInMicro / (NSInSec/fr));
  repeat
QueryPerformanceCounter(af);
  until trg<=(af-ct);
end;

I'm hoping that there's a better solution out there, because this procedure 
will end up with 100% CPU load.

I doubt it's possible to unload the CPU, since the windows scheduler is in 
milliseconds accuracy.

May be a lower (kernel/driver) level allows that.

 

thanks,

Dmitry 

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Microsecond Delay Suggestions?

[James Richters]

>An alternative would be NtDelayExecution from unit jwanative. Its interval
argument is in multiples of 100ns
>and is essentially what Windows' Sleep() uses internally.
>Note: The first argument "Alertable" determines whether the function can be
interrupted by NtAlertThread 
>(and whatever Windows API functions use that internally).

This sounds like it would work, but I can't figure out how to use it.  Do
you have an example?  
I've tried just a quick test like this:

uses
  windows,jwanative;
Var
  DelayInterval : PLarge_Integer;
  Variable1:integer;
begin
DelayInterval:=1;
Variable1:=NtDelayExecution(true,DelayInterval);
end.

It won't let me set DelayInterval with a constant, I get "Incompatible
Types: got "shortint" expected "Plarge_Integer"  
I really don't undertand these variable types that it wants.  

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Microsecond Delay Suggestions?

[James Richters]

Thank You I found the sleep procedure  Thank you for explaining that it
was looking for a pointer, that was helpful.  A little cutting and pasting
and now I have 3 more ways to sleep... Sleep_S will probably be sufficient
and is the most flexible, because if you have 1,000,000,000 seconds you
don't need precision down to 100nS.. but you have it anyway, you could
specify 10.001 seconds and it would work... it comes out to
10001 intervals... I'm not going to wait over 31 years to test
it though :)

Thanks for the help everyone, now I can adjust my delay from 36uS for
baudrates of 25 all the way to 30mS for a baudrate of 300.   I know
sleep isn't exact, it's more of a minimum and then you need to also wait for
the processor to get back to you, but I think it will be close enough
without excessive delays.

I posted it on github if anyone happens across this doing a search they can
find it here:
https://github.com/Zaaphod/FPC-Delay
 


>You need to declare a LargeInteger and pass the pointer to it to
NtDelayExecution(). LargeInteger itself is declared as a case-record 
>consisting of two 32-bit values (LowPart and HighPart) and a 64-bit value
(QuadPart). Best is you assign your value to QuadPart, as
> that sets the record in one go.
>Oh and I forgot to mention that you need to use a negative value for
relative sleeps (otherwise you'll wait until that time from the 
>system start on has passed, so "1" would be a no-op basically ;) )

>For an example see the implementation of Sleep in the SysUtils unit of the
NativeNT target: rtl/nativent/sysutils.pp (near the end of the file)

>Regards,
>Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

>i think it is the ight place i also like to rcv the software  for directly 
>controling i/o ports for fpc on wimdows
>Thank you
>Ezra

 

Ezra,

here’s the link to the FPC files.   
https://github.com/Zaaphod/FPC-Parallel-Port  

The InpOut32 driver is here: http://www.highrez.co.uk/downloads/inpout32/

I am able to control the parallel port directly under Windows 7 Professional on 
this motherboard https://www.amazon.com/gp/product/B00IW99S4A It has on board 
parallel port on a header.  

 

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Microsecond Delay Suggestions?

[James Richters]

>Look at synaser, its TBlockSerial class has a RecvTerminated method that
does just that.
>http://synapse.ararat.cz/doc/help/synaser.TBlockSerial.html#RecvTerminated
>https://sourceforge.net/p/synalist/code/HEAD/tree/trunk/
>Bye
>--
>Luca

Thank you for the suggestion and the links, that does look like it would
take care of the issue for me.
James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parallel Port Access with Free Pascal - windows

[James Richters]

>>FWIW, I ported the library to fpc, together with the test/demo software 
>>(x_pigpiod_if2).
>>The fact that the communication goes via the network opens 
>>possibilities though. I tested my port on my laptop, connected to the 
>>pi. So applications running on a remote PC could control the pi's IO.
>>
>>I have no public place to publish this software, so if anyone is 
>>interested, please ask.
>>
>
>I would be interested and I could put it up on my webserver if you like a
public spot.
>

I would also be interest in this

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Could Not Set Breakpoint - Why not?

[James Richters]

I can't seem to set any breakpoints at all with FreePascal 3.0.0 with the
text IDE.  Does anyone have any idea why this could be?  I have even tried
to set a breakpoint in a ridiculously simple program like:

 

Program Test;

Begin

Writeln;

End.

 

I am able to single step through my programs with F7, but that would take
forever to get to the part I'm having an issue with.  Do I have a setting
wrong somewhere, or need to turn something on to get breakpoints to work?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] windows graph unit questions

[James Richters]

I have a few questions about using the graph unit with windows.

 

1.Is there any way to get rid of the bar at the top that says 'graph
window application'   I don't need it or want it, I want the user locked
into my program full screen until they exit it

2.   If there is no way to get rid of the bar at the top, Is there a way
change the title of it to the name of my application instead of 'graph
window application' ?

3.   Is there any way I can make my program use only the graph
interface, and not display the command window?

 

Thanks for any advice anyone has to address these thing

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] windows graph unit questions

[James Richters]

Thank you for the help, Pierre!
 I am making some progress, but it I still have a few issues.  Here is where
I am at:

For issue #1 - getting rid of the title bar 
 Based on Pierre's information that there is a windows API call to get
rid of the titlebar, I did some searching and found that I can in fact hide
the title bar using these commands:

SetWindowLong(graphwindow, GWL_STYLE, 0);
ShowWindow(graphwindow, SW_SHOW);

However now I have two issues,  GetmaxX and getmaxY are still returning the
size that was available with the titlebar, so I don't know how bit the
screen really is.  I wrote the application to use getmaxX and getmaxy and
adjust itself to whatever size screen it is run on.  

The other issue is that it seems to have shifted the screen to the left and
up about 4pixels in each direction.. it's as if the upper left corner of the
screen is 4,4 instead of 0,0 so the top and left edge of my screen get cut
off.

I suspect that perhaps there is a way I can put these commands inside the
graph unit before the getmaxx and getmaxy variables are created and it would
come out correctly, but I really don't know how and where that happens.

For issue #2 - changing the name of the graph window application...  This
has been Resolved! 
 Pierre was spot on!   I was able to change the name of the graph window
applications using the command:

setwindowtextA(graphwindow,'My Application Name Here');

 If I can't figure out how to get rid of the windows title bar, at least
this is much more professional and makes it look like I did it on purpose :)


For issue #3 - getting rid of the command window 
   I'm still having this issue,   What happens is it opens the command
window then puts the graph application window on top of it.. at this point
everything looks and works fine, because you can't see the command window,
but in fact the command window is the active window where the keyboard is
going.   If I task switch out by hitting the windows key however, this
arrangement no longer works.. If I bring the graph application window back
to the active window, it will not respond to my keyboard, but if I bring the
command window back, then it does respond to the keyboard, but the command
window is now on top of the graph application window so I can't see what I'm
doing.

I did try {$apptype gui} and what happens is the program runs with no screen
whatsoever, neither the command window or the graph application window.   I
don't really understand what you mean by -WG option so I don't know how to
try that.
If I cannot get rid of the command window, is there some way to assign
keyboard input to the program to the graph application window when it is the
active window instead of the command window?  It's a bit of an issue because
even just clicking on the title bar of the graph application window makes
that the active window and now the program will not respond to the keyboard/

I really appreciate the help with this!

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Pierre Free
Pascal
Sent: Wednesday, August 17, 2016 9:41 AM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] windows graph unit questions

Hi,

the beauty about free open source is that you can search the sources:

> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal- 
> boun...@lists.freepascal.org] De la part de James Richters Envoyé : 
> mercredi 17 août 2016 14:42 À : 'FPC-Pascal users discussions'
> Objet : [fpc-pascal] windows graph unit questions
> 
> I have a few questions about using the graph unit with windows.
> 
> 1.    Is there any way to get rid of the bar at the top that says 
> ‘graph window application’   I don’t need it or want it, I want the 
> user locked into my program full screen until they exit it
  I think that display/hiding title bar of a window is feasible with some
standard Windows API call, it might be forbidden for specific windows type,
but I don't think that we added anything special for this in the source
code...
  I can't help you on this side, sorry.
  
> 2.   If there is no way to get rid of the bar at the top, Is there
> a way change the title of it to the name of my application instead of 
> ‘graph window application’ ?
Look for ‘graph window application’   in graph package:
Pierre@E6510-Muller cygwin-32 ~/pas/off-trunk/packages/graph $ grep -ir
'graph window application' .
./src/win32/graph.pp:windowtitle : pchar = 'Graph window application';
Note here that windowtitle is an initialized variable, that that you can
change its value before calling InitGraph.

Find where windowtitle is used:
Pierre@E6510-Muller cygwin-32 ~/pas/off-trunk/packages/graph $ grep -riw
windowt

[fpc-pascal] Finding Unsed Variable, Procedures, & Functions

[James Richters]

Is there any way to quickly identify unused variables, procedures &
functions within a large project?   I'm using FPC 3.0.0 with textmode IDE

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Finding Unsed Variable, Procedures, & Functions

[James Richters]

Thank you very much!  I found how to enable warning and hints..  phew 87
unused variables have accumulated, this will clean things up greatly!


-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Michael Van
Canneyt
Sent: Saturday, September 03, 2016 2:35 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Finding Unsed Variable, Procedures, & Functions



On Sat, 3 Sep 2016, James Richters wrote:

> Is there any way to quickly identify unused variables, procedures &
> functions within a large project?   I'm using FPC 3.0.0 with textmode IDE

The compiler tells you this for local variables if you enable warnings
and/or hints.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] WinCRT vs CRT

[James Richters]

I am working on a console application that uses the graph unit.  I want my
graphics window to be the one that accepts keyboard input,  I found out that
if I just change to 'WinCRT' instead of 'CRT' it does exactly this. however
there is a problem with WinCRT that I do not understand.  Please reference
my test program: 

 

 

Program KeyTestWin.pas;

Uses Graph,

// CRT;

 WinCRT;

Var

   Test:Char;

   GD,GM:Integer;

Begin

   gd:=detect;

   gm:=0;

   Initgraph(gd,gm,'');

   repeat

  Test:=readkey;

  if Test<>Chr(0) then

 Writeln ('KeyCode: ',Ord(Test))

  Else

 begin

Test := Readkey;

Writeln ('Extended: ',Ord(Test));

 end;

   Until Test=Chr(27);

End.

 

 

If I comment out WinCRT and uncomment CRT and run it,  then I get almost the
full keyboard, for example 

ALT-X = Extended: 45

CTRL *= Extended: 150

CTRL 8 = Extended: 9

F10 = Extended: 68

CRTL F10 = Extended: 103

ALT F10 = Extended: 113

I do notice just a few keys that windows intercepts, like F11 makes it full
screen and my application never sees the keystroke, but actually very few
keys are intercepted by windows like this.

 

But with WinCRT instead of CRT, None of these and many more report anything
at all.. it's as if I didn't even hit a key.  

NONE of the keys wit ALT respond at all

CTRL works with most Letters but NO number

F10, F11, and F12 do not work.. etc. etc. etc..  you get the idea, it's
extremely limited.

 

Does anyone have any idea why this is happening or if there is another way
to get keyboard input on the graph window and be able to use the entire
keyboard?

 

Any help is greatly appreciated!

 

James

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] pull request: Add missing CTRL keys to wincrt unit

[James Richters]

That was me,  Sorry about that,  I did not realize it was a read only
repository,  I downloaded a fork of it to my desktop a while ago, so when I
had a proposed change to it, I just made a pull request the way I normally
do with git projects.

I have posted the issue here:
http://mantis.freepascal.org/view.php?id=30599  and have attached the file
to it.  I'm not really familiar with this system, so I hope I'm doing it
right.


-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Graeme
Geldenhuys
Sent: Tuesday, September 13, 2016 6:15 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] pull request: Add missing CTRL keys to wincrt unit


> Somebody made a contribution via my Git mirror of the FPC repository.


File Changes

M packages/graph/src/win32/wincrt.pp (120)

Patch Links:

https://github.com/graemeg/freepascal/pull/10.patch
https://github.com/graemeg/freepascal/pull/10.diff



Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Reed-Solomon algorithm

[James Richters]

I was able to use a C library by creating the following unit, the hardest part 
was getting variable types to match.   Perhaps this example of linking a C 
library to Free Pascal will help.

 

James

 

 

Unit InpOut32;

 

Interface

   Function IsInpOutDriverOpen:Boolean;{$Ifndef Win32} cdecl {$Else} stdcall 
{$EndIf};

   Function IsXP64Bit:Boolean;{$Ifndef Win32} cdecl {$Else} stdcall {$EndIf};

   Function  Inp32(Port:LongInt):Byte;{$Ifndef Win32} cdecl {$Else} stdcall 
{$EndIf};

   Procedure Out32(Port:LongInt; Value:Byte);{$Ifndef Win32} cdecl {$Else} 
stdcall {$EndIf};

   Function DlPortReadPortUChar(Port:LongInt):Char;{$Ifndef Win32} cdecl 
{$Else} stdcall {$EndIf};

   Procedure DlPortWritePortUChar(Port:LongInt; Value:Char);{$Ifndef Win32} 
cdecl {$Else} stdcall {$EndIf};

   Function DlPortReadPortUShort(Port:LongInt):Word;{$Ifndef Win32} cdecl 
{$Else} stdcall {$EndIf};

   Procedure DlPortWritePortUShort(Port:LongInt; Value:Word);{$Ifndef Win32} 
cdecl {$Else} stdcall {$EndIf};

 

Implementation

   Function IsInpOutDriverOpen; {$Ifndef Win32} cdecl {$Else} stdcall {$EndIf}; 
external 'inpout32.DLL';

   Function IsXP64Bit; {$Ifndef Win32} cdecl {$Else} stdcall {$EndIf}; external 
'inpout32.DLL';

   Function Inp32; {$Ifndef Win32} cdecl {$Else} stdcall {$EndIf}; external 
'inpout32.DLL';

   Procedure Out32; {$Ifndef Win32} cdecl {$Else} stdcall {$EndIf}; external 
'inpout32.DLL';

   Function DlPortReadPortUChar; {$Ifndef Win32} cdecl {$Else} stdcall 
{$EndIf}; external 'inpout32.DLL';

   Procedure DlPortWritePortUChar; {$Ifndef Win32} cdecl {$Else} stdcall 
{$EndIf}; external 'inpout32.DLL';

   Function DlPortReadPortUShort; {$Ifndef Win32} cdecl {$Else} stdcall 
{$EndIf}; external 'inpout32.DLL';

   Procedure DlPortWritePortUShort; {$Ifndef Win32} cdecl {$Else} stdcall 
{$EndIf}; external 'inpout32.DLL';

 

End.

 

 

 

From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Sandro Cumerlato
Sent: Thursday, September 15, 2016 12:52 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Reed-Solomon algorithm

 

A quick search on Google pointed me to:

https://github.com/catid/longhair

It is a C library implementing the Reed Solomon algorithm. 

I think that it's possible to build a dll from sources and create the 
corresponding fpc binding from the .h include file.

Best regards. 

Sandro Cumerlato 

 

On 15 Sep 2016 18:29, "duilio foschi" mailto:octopush...@gmail.com> > wrote:

can somebody point me to the algorithm above written in Pascal ?

As an alternative, can somebody point me to the algorithm above
written in some DLL I could use from FPC ?

Thank you

Peppe Polpo
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Underscores in numerical literals - grouping

[James Richters]

>IOW I don't like editors that store in formats that are nearly useless in
other editors.

I total agree with this statement,  proportional editors are only good if
you are the only one who will ever look at the code, if anyone else EVER
looks at it, it's just a giant mess, you can't put snippets of it in
pastebin for ask for help, or really collaborate in anyway with anyone else
without manually re-formatting it for a monospaced font, and there is really
no point in even bothering.  I find Consolas VERY easy on the eyes and have
no problems organizing my code with it.   I, l, 1, AND | are all distinctly
different with it as well as 0 and O.I have a REAL pet peeve about
font's that these characters look identical, unfortunately Arial is one of
them, and guess what font stock installations of windows use..  and the VAST
majority of windows users have no idea it can be changed, never mind how to
change it..   My son's teacher sent home spelling words typed in Arial and
my son was spelling Illusion - i i i u s i o n because it was just not clear
what the characters were.  When writing code we have a LOT of variables and
such that are not normal readable words so it's a really bad idea to have a
font with any questionability in what the characters are at all.  Also a lot
of proportional font indent corrections only work if your font is a
particular size,  if you change your mind and decide you are getting older
and now need a larger font than you did 10 years ago,  now all your code
that used to look good, is all misaligned.  The only way code will be
properly aligned all the time, in any editor, at any size is to use a
monospaced font, and do not use tabs at all, set your editor to insert
spaces for tabs.   The only thing that ever looks good all the time to
everyone is a nice grid of character cells.   Even if an editor COULD make
it come out right with a proportional font, you are back to now having code
that only one person can ever read, making it useless,  so why bother with
the effort at all... it's also impossible to autocorrect every situation
with a proportional font.. for example:

P_Range[1,0]:=0;
I_Range[1,1]:=0;
W_Range[2,0]:=0;
R_Range[2,1]:=1;

With a monospaced font, they are all perfectly aligned, but with a
proportional font, there is nothing the editor could do automatically to fix
this.  Sure you could put some space between the variable and the [ and try
to adjust that space in a reverse proportional method, but that doesn't make
it look right, and you CAN'T stick any space in the actual variable name to
make all the _Range align again once the initial proportional letter has
fouled everything up.   I have been programming for a long time, (also
started with a VIC20) and I just don't see how structured programming can be
done effectively with a proportional font.. you will spend more time trying
to force the proportional font to look good than actual programming.  As it
mentions on the Freepascal wiki, pascal itself doesn't require any
formatting, you can put your whole program on one long line if you want, but
no one else will ever understand it.  The formatting is for our benefit, so
why would you use some kind of editor that now takes all your nice
formatting and saves it in a way that requires a specific editor to read.
The spacing and formatting is much more important that the actual reading of
individual 'words' in a program, you need to identify the variable you are
working on quickly and follow the structure accurately, thus monospaced
fonts are far and away the best choice for this. 

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Marco van de
Voort
Sent: Monday, November 21, 2016 2:26 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Underscores in numerical literals - grouping

In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]
> On 2016-11-21 16:05, J?rgen Hestermann wrote:
> > Why?
> > I like monospaced fonts for code very much.
> 
> See my reply to Stephen. More intelligent editors can let you use 
> monospaced and proportional fonts with ease - yet you don't loose code 
> alignment, indentation etc. Elastic Tabstops do just that. It's simply 
> about editors becoming more clever about there text rendering instead 
> of forcing everything into a grid of character cells.
> 
> Plus proportional fonts overall look much better than monospaced ones. 
> ;-)

IMHO editors should be like network protocols. Liberal in what you accept,
and conservative in what you write.

IOW I don't like editors that store in formats that are nearly useless in
other editors.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists

Re: [fpc-pascal] Underscores in numerical literals - grouping

[James Richters]

I use notepad++ Vertical editing ALL THE TIME, you cannot do vertical editing 
effectively with a proportional font.   For those who aren't familiar with it, 
you can hold down ALT and highlight many lines vertically making a very tall 
cursor, you can then start typing and what you type will be on all lines with 
the tall cursor.. thus you can very quickly and easily shift entire blocks 
over, or even fix something on many lines at once.  This is very helpful when 
you have something that used to be inline and now you want to make a procedure 
out of it for example.

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Graeme Geldenhuys
Sent: Monday, November 21, 2016 6:42 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Underscores in numerical literals - grouping

On 2016-11-21 19:06, Sven Barth wrote:
> but also due to the ability to easily compare different names simply 
> based on their visual length without having to decide whether the 
> difference is due to the name or the different sized characters.


And here is an example of the exact problem, but when using a monospaced font. 
The spelling error is spotted much easier when using a proportional font.

View the following URL and search for “Proportional fonts can make it easier to 
spot typos.” - it’s about 3/4 down the page.

  http://input.fontbureau.com/info/

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Underscores in numerical literals - grouping

[James Richters]

The problem with your example 
"text_with_tabs_Input-Sans_proportional_font_and_ET.png"  is that the 
underscores and the word Range and the brackets are all out of alignment,  even 
though everything is re-aligned again with the :=  I prefer the array elements 
to also be aligned as well.   In my opinion this misalignment caused by the 
proportional font is more annoying than the monospaced font.  

> P_Range[1,0]:=0;
> I_Range[1,1]:=0;
> W_Range[2,0]:=0;
> R_Range[2,1]:=1;

>I prefer spacing between programming language symbols, even though I have 
>syntax highlighting enabled too. So I would write the above as:
>
>P_Range[1,0] := 0;
>I_Range[1,1] := 0;
>W_Range[2,0] := 0;
>R_Range[2,1] := 1;
>
>I normally use a monospaced font - Raize font to be exact - which is a bitmap 
>based font.
>
>But to give you an idea of what the above source code will look like in other 
>editors. Take my code sample above, replace the spaces with single TAB 
>(U+0009) characters. This not only
>reduces the file size, it also reduces the number of characters any parser 
>needs to process (thus faster parsing and compiling). :)
>
>See attached screenshots.
>
>  text_with_tabs_monospaced_font.png
> This is viewed with EditPad Pro, using a monospaced font and the
>  TAB size was set to be equal to 2 spaces in width. Other editors
>  text to default TAB width to equals 4 or 8 spaces. Point is, the
> text will always align. EditPad Pro doesn't support ET.

>  text_with_tabs_Input-Sans_proportional_font_and_ET.png
> Here I used my experimental Elastic Tabstops enable text editor
> with a proportional font (Input Sans). Note that the text is still
> perfectly aligned. Also note that even though I use a proportional
> font, the 1 (one) and 0 (zero) characters are easily
> distinguishable from l, I, L, o and O letters. The 3rd note is
>  that with ET, the minimum width and padding are defined in pixels,
> not [Space] character widths (like most editors do with TAB
> widths).

>So this just shows that alignment can be achieved with or without monospaced 
>fonts. Also that not all fonts are created equal. Just like not all monospaced 
>fonts are appropriate for >programming (tricky letters and numbers). Also not 
>all proportional fonts are created equal - some are better suited to 
>programming code than others. The "Input Sans" font is actually very >nice for 
>source code.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Readln a password

[James Richters]

Here is how I read passwords... it generates a random character and displays
that so someone looking over your shoulder things those characters are the
password
It uses readkey which does not display on the screen, one character at a
time

Function Readpw:String;
Var
   Pwstring : String;
   pwchar   :Char;
Begin
   Randomize;
   Pwstring:='';
   Repeat
  Pwchar:=readkey;
  If PwChar<>#13 Then
 Begin
pwstring:=pwstring+Pwchar;
Write(chr(Random(77)+33))
 End;
   until pwchar=#13;
   Readpw:=pwstring;
end;

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Adriaan van Os
Sent: Sunday, November 27, 2016 8:24 AM
To: FPC-Pascal users discussions 
Subject: [fpc-pascal] Readln a password

I wonder what the recommended way is to readln a password from console, as a
standard Readln echoes the password.

1. SetConsoleMode seems to be Windows-specific

2. On Mac OS X, a loop with a Crt.ReadKey until char(13) works in
Terminal.app, but behaves strange in the Xcode Console window (more precise,
uses Crt doesn't seem to be compatible with the Xcode
Console)

3. On Mac OS X, executing '/bin/stty -echo' gives an error message 'stty:
stdin isn't a terminal' 
(both in Terminal.appand in the Xcode Console window)

4. I experimented with '/usr/bin/read -s -p Password:' but couldn't get it
working from FPC.

Regards,

Adriaan van Os
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Readln a password

[James Richters]

I would like to mention that if you store your password in a constant like
this:
const
   password='mypassword' 

then if someone edits your exe file with any text editor, your password will
be in there as text and easy to find.

I have used this method to get around this...  I store a huge string like
this:
   Emailinfo1=
'êE1669>)d2LU`j=LBK;=]=2mWX3d]jei/m*HzY:`/74F8H0,0/,.*,-0+--*/*-,*+-++,-,/7(
L36dLUB/IS9(d537A:A1j:VbipIYNV=JfB3{[_>pjuPGa5SXX`ko7}sv]/M*m[KSjR[UP.^3mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Adriaan van Os
Sent: Sunday, November 27, 2016 8:24 AM
To: FPC-Pascal users discussions 
Subject: [fpc-pascal] Readln a password

I wonder what the recommended way is to readln a password from console, as a
standard Readln echoes the password.

1. SetConsoleMode seems to be Windows-specific

2. On Mac OS X, a loop with a Crt.ReadKey until char(13) works in
Terminal.app, but behaves strange in the Xcode Console window (more precise,
uses Crt doesn't seem to be compatible with the Xcode
Console)

3. On Mac OS X, executing '/bin/stty -echo' gives an error message 'stty:
stdin isn't a terminal' 
(both in Terminal.appand in the Xcode Console window)

4. I experimented with '/usr/bin/read -s -p Password:' but couldn't get it
working from FPC.

Regards,

Adriaan van Os
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Readln a password

[James Richters]

Shouldn't an extremely basic function like readkey be cross-platform?

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Michael Van
Canneyt
Sent: Sunday, November 27, 2016 12:07 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Readln a password



On Sun, 27 Nov 2016, Adriaan van Os wrote:

>> Dmitry Boyarintsev wrote:
>> 
>>> I'd think you want something simlar on unix.
>>> Take a look at man 4 termios
>>> specifically at local flag named "ECHO".
>>> you want to disable it via tcsetattr() Â (TermIO unit)
>> 
>> Thanks for the hint. I haven't yet tried it, but I would expect it to 
>> fail,as stty (see stty.c in GNU coreutils) calls tcsetattr and stty 
>> fails reporting 'stty: stdin isn't a terminal' .
>
> No, it was my own fault. I were executing '/bin/stty -echo' with 
> AssignStreams and then StdIn is indeed not a terminal, but a pipe. 
> When I execute it normally, then stty does work, so I expect tcsetattr to
work too.
>
> So, we can now use Readln without echoing in Terminal.app. There is 
> still echoing to the Xcode Console window, but let's assume that is a 
> bug or limitation of Xcode.
>
> Maybe something to add to the fpc runtime libs ?

If you mean in a cross-platform way, I think we would welcome patches :)

Michael.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

I have a freepascal Windows console application that I recently ported over 
from DOS Turbo Pascal.   I am have a small settings file that I write to disk 
that keeps getting corrupted.  It happens only occasionally, but it’s always 
this one file, no others.Do I need to do something specific to force 
windows to write the file to disk and not have it in some kind of cache or 
buffer?   I am using the following code to write the file:

 

 

   Assign(BitFile,'BitSave.pax');

   ReWrite(BitFile);

   WriteLn(BitFile,XADJ:1:8);

   WriteLn(BitFile,YADJ:1:8);

   WriteLn(BitFile,ZADJ:1:8);

   WriteLn(BitFile,WADJ:1:8);

   WriteLn(BitFile,AADJ:1:8);

   WriteLn(BitFile,TADJ:1:8);

   WriteLn(BitFile,VADJ:1:8);

   WriteLn(BitFile,UADJ:1:8);

   WriteLn(BitFile,CurrentTool);

   WriteLn(Bitfile,P_Value[4]);

   Close(BitFile); 

 

The above only happens when I make a change to one of the settings, and the 
system is never having any issue at that time, yet upon occasion I will have an 
error opening the file and when I inspect it, it’s just a long string of [nul]. 
  I am not leaving the file open, I’m assigning it, writing to it, then closing 
it, so there should be no opportunity for data to be lost.  I am having the 
same issue on about 8 different computers, most of which are running solid 
state hard drives. It’s always just this one file that is affected, nothing 
else.  No other process ever uses this file, so it must be my freepascal 
program that is leaving the file in a vulnerable state.

My understanding was the Close(file); would save the file all the way to disk 
and flush any buffers that were holding it, but I’m wondering if that was only 
true for DOS and there is some other windows cache or buffer that also needs to 
be instructed to flush to truly save the file all the way to disk and close it.

 

Thanks for any advice on this

 

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

Thanks for the advice on things to look at. 

 

Here is some more information.  First of all, this happens extremely rarely, 
about once a month or two on a pc here and another there, but it’s odd that 
it’s always this one file, and it should not be happening at all.I’m using 
turbo pascal compatibility mode, and it’s a console application, there is no 
multi threading going on, it’s straight inline code.  No other programs on the 
system ever access this file and there is no reason to open it with a text 
editor or anything like that.The error I get is when trying to open the 
file to read it.  It’s something like read past end of file, because the 
corrupted file is just one long line, once I read that, the second read is past 
the end of file.  I can do checking to get the file length and avoid the error, 
but that doesn’t solve the real issue, which is that the data that is supposed 
to be in the file is just gone.  

 

Bitfile is type TEXT like this: 

 

Bitfile: Text;

 

and my variables are all doubles.  

Normally what happens is, everything is fine for a month or two, but then one 
day someone will come in and notice the error on the screen, it was fine the 
night before, the program running overnight, in the morning the program is not 
running,  and when the attempt is made to run it,  The error is found and the 
cause of the error is BitSave.pax has been corrupted and is now a long string 
of [nul]   the computers this runs on are all windows 10 with Samsung solid 
state hard drives.I suspect that the majority of the time, this has 
happened due to winders doing an automatic update and restarting without 
permission as windows 10 annoyingly likes to do, thus crashing my program in 
order to do this restart that is SO important.  I have shut off windows update 
via group policy, but still had the problem since, however I cannot be certain 
there was not a power failure.   The computers are set to re-power up after 
power loss in BIOS and the program is set to run on startup, in fact the 
computers have no other function than to run this one program, they are never 
used for anything else.  The procedure that writes out this file is only ever 
used when one of the variables is changed, and they can only be changed by 
manual input, which is not happening anymore when the issue occurs.   The thing 
is, even if windows forced a restart while my program was running this file 
should have been closed at the time, because if someone was standing there 
editing the variables, they would see the restart notification and close the 
program first, or be able to tell me they had a power failure. 

 

As a temporary measure, I’m just writing out the file twice so at least I have 
a backup, but I don’t see why the backup would not be corrupted by this same 
issue, so that’s probably pretty useless.

Unfortunately this is difficult to troubleshoot because it happens so rarely. I 
have tried to force it to happen by terminating my program with task manager 
and cannot cause the file to be corrupted.   I have not yet tried to duplicate 
the error by shutting down the system while the program is running.  I could 
try that. If it does turn out to be an issue with my program running during 
shutdown,  is there some way I can detect a pending shutdown and exit normally 
before the shutdown happens?   It wouldn’t really solve the cause of the issue, 
but it would possibly help prevent some of the occurrences related to 
shutdowns, but would not help with power failures.

 

I am unable to use Try in turbo pascal compatible mode.  If I use it, I get 
identifier not found ‘Try’   If I attempt to compile in some mode other than 
turbo pascal compatible, I end up with thousands of other errors, so I would 
pretty much have to do a complete re-write.   I can’t see how the close could 
not be run, there is no way out of my procedure without running it since it’s a 
single thread console application.

 

James

 

 

From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Santiago A.
Sent: Wednesday, February 22, 2017 3:48 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

 

El 21/02/2017 a las 22:12, James Richters escribió:

 

Thanks for any advice on this


My first action would be to guarantee that the file is closed with a 
try...finally.

AssignFile(BitFile,'BitSave.pax'); 

ReWrite(BitFile);

try



finally

  CloseFile(BitFile);

end;


Second:

Do you have the file opened with an editor, or things like that, while running 
the program?.

Third:

Check that all variables have valid values and that values are converted to 
string properly to be printable.

Fourth:

Do you use somewhere {$I+} {$I-}? I also had some problems with that with old 
programs.

Fourth:

What's the type BitFile? 
BitFile: TextFile;
BitFile: File;

Maybe using writeln with non-textfile 

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

Here is the procedure that reads the file. It is only read once when the 
program is started, then written to when changes are made.

I don’t have a good reason for having a different file variable name in my read 
procedure than my write procedure, but those are local varaibles to the 
procedures anyway so it shouldn’t matter what I call them.

 

Var

   locfile : text;

If FileExists('Bitsave.pax') Then

Begin

   Writeln('BitSave.pax Found, Loading... ');

   Assign(locfile,'BitSave.pax');

   reset(locfile);

   ReadLn(locfile,XAdj);

   ReadLn(locfile,YAdj);

   ReadLn(locfile,ZAdj);

   ReadLn(locfile,WAdj);

   ReadLn(locfile,AAdj);

   ReadLn(locfile,TAdj);

   ReadLn(locfile,VAdj);

   ReadLn(locfile,UAdj);

   ReadLn(locfile,CurrentTool);

   ReadLn(locfile,P_Value[4]);

   Close(locfile);

End

 

I will do as you suggest and read what I just thought I wrote back to verify 
it.   I may also incorporate some kind of checksum as well and it wouldn’t be a 
bad idea to check how many lines are in the file before I try to read it, just 
to make sure I don’t get read past end of file error.  It seems like a lot just 
to save just 10 numbers, but it’s a pain if those numbers are gone!I will 
also try flush and {$i-}  as well.  

 

Thanks to everyone for your advice and help

 

Jim

 

From: fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Santiago A.
Sent: Wednesday, February 22, 2017 11:07 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

 

El 22/02/2017 a las 13:17, James Richters escribió:

The error I get is when trying to open the file to read it.  It’s something 
like read past end of file, because the corrupted file is just one long line, 
once I read that, the second read is past the end of file.  I can do checking 
to get the file length and avoid the error, but that doesn’t solve the real 
issue, which is that the data that is supposed to be in the file is just gone.  


Just two lines of research ;-)

A) While you are reading the file you call the procedure that writes it.

B) The is a bug, not in writing the part, but in the reading code: Somewhere 
when you read the file, you don't close it, so the file remains open. Usually 
it's not a big issue, you can open the file several times, and when you close 
the program everything is closed. But some times, when a parameter is changed 
you rewrite it while it is still open and everything gets messed. So this two 
events must happen, the program has executed the part of code that lets the 
file open and next a parameter is changed.




 

The thing is, even if windows forced a restart while my program was running 
this file should have been closed at the time, because if someone was standing 
there editing the variables, they would see the restart notification and close 
the program first, or be able to tell me they had a power failure. 

 

As a temporary measure, I’m just writing out the file twice so at least I have 
a backup, but I don’t see why the backup would not be corrupted by this same 
issue, so that’s probably pretty useless.

Yes, I think that's the way to go.

1) Before writing, read it and if it's ok make a backup of the file
2) Write the file.
3) Read again what you have written to check whether it's ok. 
4) Make a second backup.

That way, when you load parameters you have two backups to recover. And maybe a 
clue of what's going wrong.
Beside, I would add a timestamp inside the file.

In addition, you could use flush and {$I-}





-- 
Saludos
 
Santiago A.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

I suppose a virus scanner could access it, I didn't think of that.   I guess
I should have said no other program intentionally access the file.   It's
just a way for me to store some variables and get them back, it serves no
other purpose.   

-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Jonas Maebe
Sent: Wednesday, February 22, 2017 3:47 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

On 22/02/17 13:17, James Richters wrote:
> No other programs on the system ever access this file

Not even virus scanners?


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

Thanks for the advice everyone.   It is very much appreciated.   I have been
working on a combination of ideas here.  Currently I am doing an MD5sum of a
string created from all my variables concatenated together and writing that
as the second to the last line of the file, I also am writing some fixed
text at the beginning and end of the file as suggested so I can check for
variables being overwritten in memory, great idea!   I am then reading the
file back to verify it has written properly, making a backup, checking that,
and also using ioresults as below. I will probably rename the file as well,
and exclude it from virus checkers.  When I read the file I can verify the
MD5sum and if that test fails, I'll just automatically try the backup, If
that also fails the MD5sum I'll notify the user.  

Thanks again for all the help

James
-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Klaus Hartnegg
Sent: Thursday, February 23, 2017 6:33 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

Am 21.02.2017 um 22:12 schrieb James Richters:
>  Assign(BitFile,'BitSave.pax');
{$I-}
>  ReWrite(BitFile);
if ioresult <> 0 then
   writeln ('error opening pax file');
>  WriteLn(BitFile,XADJ:1:8);
>  WriteLn(BitFile,YADJ:1:8);
>  WriteLn(BitFile,ZADJ:1:8);
>  WriteLn(BitFile,WADJ:1:8);
>  WriteLn(BitFile,AADJ:1:8);
>  WriteLn(BitFile,TADJ:1:8);
>  WriteLn(BitFile,VADJ:1:8);
>  WriteLn(BitFile,UADJ:1:8);
>  WriteLn(BitFile,CurrentTool);
>  WriteLn(Bitfile,P_Value[4]);
writeln (bitfile, 'EOF');
if ioresult <> 0 then
   writeln ('error writing pax file');
>  Close(BitFile);
if ioresult <> 0 then
   writeln ('error closing pax file');
{$I+}

This writes something at the end of the file that does not come from a
variable. Next time the error happens, you can check if that is present. 
Then your variables were overwritten in memory. Also it checks for errors.
And I would disable antivirus or at least tell it to not scan this file.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

I am still having this issue.  I've managed to narrow down what is happening
some.   The problem is my data is not actually being written all the way to
disk.   I now have a repeatable proven method to reproduce the issue.  Here
is the sequence.

In my freepascal console application, I create the file
Assign file
Rewrite file
Writeln file 
Writeln file
Writeln file ...
Flush file
Close file

I then immediately read back the file, and all is good.  I even look at the
file with notepad++ to see that the data is correct and it is fine.

If I then power off the test computer (not doing a correct windows shutdown,
this simulates an unattended power failure) when it boots back up, my file
has the correct date and time and the correct length, hovever the contents
of the file is a string of $00 with no other characters, no carriage returns
and no linefeeds, however the number of $00s is EXACTLY how many bytes the
file should have been.  It's like the file was allocated but data not
actually written to disk yet... but I thought Close (file) was supposed to
do that.I think I am dealing with some kind of disk caching going on
here, but I'm not sure how to force my files to commit all the way to disk.
I should note that these systems are all using Samsung SSDs in them, perhaps
there is some SSD weirdness going on? I also notice it's not just this
one file that is affected, but EVERY SINGLE FILE I create with freepascal,
this is the only one I notice because the other ones are all work files that
end up being re-created every time I run my program, but I checked them all
and they are all exactly the same..  correct lengths but all data is a
string of 00s   

I'm thinking of just disabling all write behind caching in windows and on
the SSD if I can figure it out,  it's not needed anyway anymore because SSDs
are way more than fast enough, and I would rather wait for my data to be
written NOW instead of it NOT getting written later!!The problem with
solving this by disabling write caching is that I can never be sure that
this was done.  So I would like to find a real solution that would force my
files all the way to disk on my own without depending on the system being
configured a certain way.   I really need these tiny files to survive power
failures.

Thanks for any advice on how to do this

James



-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of James Richters
Sent: Friday, February 24, 2017 1:53 PM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

Thanks for the advice everyone.   It is very much appreciated.   I have been
working on a combination of ideas here.  Currently I am doing an MD5sum of a
string created from all my variables concatenated together and writing that
as the second to the last line of the file, I also am writing some fixed
text at the beginning and end of the file as suggested so I can check for
variables being overwritten in memory, great idea!   I am then reading the
file back to verify it has written properly, making a backup, checking that,
and also using ioresults as below. I will probably rename the file as well,
and exclude it from virus checkers.  When I read the file I can verify the
MD5sum and if that test fails, I'll just automatically try the backup, If
that also fails the MD5sum I'll notify the user.  

Thanks again for all the help

James
-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Klaus Hartnegg
Sent: Thursday, February 23, 2017 6:33 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

Am 21.02.2017 um 22:12 schrieb James Richters:
>  Assign(BitFile,'BitSave.pax');
{$I-}
>  ReWrite(BitFile);
if ioresult <> 0 then
   writeln ('error opening pax file');
>  WriteLn(BitFile,XADJ:1:8);
>  WriteLn(BitFile,YADJ:1:8);
>  WriteLn(BitFile,ZADJ:1:8);
>  WriteLn(BitFile,WADJ:1:8);
>  WriteLn(BitFile,AADJ:1:8);
>  WriteLn(BitFile,TADJ:1:8);
>  WriteLn(BitFile,VADJ:1:8);
>  WriteLn(BitFile,UADJ:1:8);
>  WriteLn(BitFile,CurrentTool);
>  WriteLn(Bitfile,P_Value[4]);
writeln (bitfile, 'EOF');
if ioresult <> 0 then
   writeln ('error writing pax file');
>  Close(BitFile);
if ioresult <> 0 then
   writeln ('error closing pax file');
{$I+}

This writes something at the end of the file that does not come from a
variable. Next time the error happens, you can check if that is present. 
Then your variables were overwritten in memory. Also it checks for errors.
And I would disable antivirus or at least tell it to not scan this file.
___
fpc-pascal mail

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

I have not tried FlushFileBuffers() yet, so I just tried it now,  I am getting 
the same results.   I have also tried disabling write caching in disk 
management and STILL have the same results.   I am now thinking this is some 
caching being done on the SSD that is ignoring FlushFileBuffers()  Probably a 
'feature' designed to help extend the life of the SSD, but making it useless to 
store data that needs to survive a power failure.

I have tried running my freepascal program on a normal mechanical hard disk and 
flushfilebuffers() seems to be working as expected, Data is getting actually 
written to the disk and my 'power failure' is not affecting the data at all, 
but on the SSD, it's still just a correct length file of 00s

Does anyone know of a way to force critical data to be written to a SSD so it's 
not lost during a power failure?  

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Henry Vermaak
Sent: Tuesday, March 21, 2017 11:08 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

On Tue, Mar 21, 2017 at 10:39:23AM -0400, James Richters wrote:
> I am still having this issue.  I've managed to narrow down what is happening
> some.   The problem is my data is not actually being written all the way to
> disk.   I now have a repeatable proven method to reproduce the issue.  Here
> is the sequence.
> 
> In my freepascal console application, I create the file Assign file 
> Rewrite file Writeln file Writeln file Writeln file ...
> Flush file

Have you tried using the FlushFileBuffers() Windows API?  Something like
this:

FlushFileBuffers(TextRec(AFile).Handle);

Add "windows" to the uses clause, obviously.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

No, it is not only freepascal, but not every program either. 

I have just done some quick tests check this.  I have not done any real testing 
to prove whether these are repeatable all the time or not yet.
A file saved with notepad ++ is lost
Partial email drafts in outlook are saved
A file created with Echo "test" > test.txt is saved
Copying a file from the command line seems to end up saving both the source and 
destination.I tried saving a file with notepad++ then copying the file, and 
after the power failure, both the source and destination were complete.   But 
saving with notepad ++ will always be a string of 00s.  

I wonder if this is a 32/64 bit issue.   Notepad ++ and my free pascal programs 
are both 32bit. 

Perhaps until I can figure out what the copy command is doing to save the file 
to disk, I can just shell execute a copy command on my files and that will end 
up saving them.  I guess if I did that I could run my entire program from a ram 
drive and save some SSD activity and only copy the important files back to the 
SSD and only when they actually change.  

James





-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Santiago A.
Sent: Wednesday, March 22, 2017 4:40 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

El 21/03/2017 a las 15:39, James Richters escribió:
> I should note that these systems are all using Samsung SSDs in them, 
> perhaps there is some SSD weirdness going on?
Yes, I think so.  SSD is special.

The SSD technology like any flash memories have a limited number of rewrites, 
so there are strategies to rewrite as less as possible. In the case of SSD they 
are even more aggressive, because they are expensive .Some of these strategies 
are implemented in the OS in driver level, but some in firmware of the device.  
So, it is possible that OS can't completely force the real write.

> I also notice it's not just this
> one file that is affected, but EVERY SINGLE FILE I create with 
> freepascal,
Only with freepascal?

Try it for a file generated from command line

echo "test" > filetest.txt

And do the same checks... edit notepad++... turnoff power etc
> configured a certain way.   I really need these tiny files to survive power
> failures.
Power failures are always a problem for persistent storage. Caching is a 
trade-off between speed and security. In the case of SSD there is a third 
point: Minimize the real writes on disk. So, if you want security against power 
failures, SSD is not the best idea.

By the way. What about a SAI? ;-)


--
Saludos

Santiago A.
s...@ciberpiula.net

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

Thanks for the link and information on atomic writes.   It seems like a much 
better method.   My current scheme is to copy everything to a ramdrive upon 
boot.  Here I can do what I want with my files and if the machine crashes, the 
files I started with on the hard drive have not been affected.  Now for the 
tricky part, If I change a file, and want to save the change back to the hard 
drive in a way that is either 100% successful or 0% successful.   My thinking 
is that if I create the new file on my ram drive, and my program is still 
running, I can then perform the following sequence:

Copy the file to the hard drive with a temporary name
Flush all writes to above file
Delete previous backup file
Rename the original file to backup file name
Rename the new recently copied file to the original name

At this point I should have the current data with the original name and a 
backup of the previous data in case something goes wrong before the sequence 
completes.

I would like to do this without shell execute, and it seems my best bet is to 
use windows api calls instead of pascal functions.   I have FlushFileBuffers() 
working.  For the copy should I use MoveFileEx()   Should I use DeleteFile() to 
delete the previous backup and Rename() to rename the files or is there a 
better way?  Will I need to do something for commit the rename to disk?

Thanks for the help with this

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Karoly Balogh (Charlie/SGR)
Sent: Wednesday, March 22, 2017 9:13 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

Hi,

On Wed, 22 Mar 2017, Karoly Balogh (Charlie/SGR) wrote:

> However, please note that transactional file handling on power loss is 
> a quite delicate scenario, so you might not be able to solve all the 
> related problems with this - what happens exactly when you get a power 
> loss during a write, might be matter of pure luck.
>
> The usual way to work this problem around on Linux systems at least, 
> is to write a new file, then do an overwriting rename to the old file name.
> There rename is an "atomic" operation, which will be either committed 
> to the disk or not, but if it was unsuccessful, you won't end up with 
> half-written files. But IIRC Windows didn't support atomic renames. 
> Maybe someone with more Windows knowledge will fix me. You definitely 
> don't want to implement a copy though, and that's anything but atomic.

Actually, this blogpost which I've just found also details the algorithm how 
you should do it, from a Windows perspective:

https://blogs.msdn.microsoft.com/adioltean/2005/12/28/how-to-do-atomic-writes-in-a-file/

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

I'm trying to use copyfile and cannot get it to work,  anyone have any ideas?

I'm using the procedure below.  My writeln showing the contents of the 
variables seems to indicate they are correct.  The souce file does exist and is 
correct, the destination file does not exitst.
I get an error 50 which is 

ERROR_NOT_SUPPORTED  50 (0x32)
The request is not supported.

I don't see how copying a file I just created is not supported.  Does anyone 
have any ideas how to get this to work or what I may be doing wrong, or if 
there is a better way I should be copying my file?   I've tried using single 
quotes and double quotes around the file names.

Thanks

James


Uses
   Serial,Windows,jwanative,sysutils;

Procedure Copy_Backup_Rename(CBR_Filename:String);
var
  fileSource, fileDest: string;
  resultsofit : Boolean;

Begin
   fileSource := chr(39)+Prog_Drive+Prog_Path+'\'+CBR_Filename+'.tmp'+chr(39);
   fileDest := chr(39)+'C:'+Prog_Path+'\'+CBR_Filename+'.temp'+chr(39);
   writeln (filesource+''+filedest);
   resultsofit := CopyFile(PChar(fileSource), PChar(fileDest), False);
   writeln (resultsofit);
   writeln(getlasterror);
End;

Console output:
'C:\ProMill\BitTool.tmp''C:\ProMill\BitTool.temp'
FALSE
50

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

Thanks for the response, it got me on the right track and I got it working.

 

I originally did try “ instead of ‘ and have the same results.  I was using ‘  
because of the example here: http://wiki.freepascal.org/CopyFile 

 

I was able to get it to work without any ‘ or “  I even did a test with a space 
in the file name and it worked fine without  “   

It appears The function must put “ around it for you.

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Sandro Cumerlato
Sent: Thursday, March 23, 2017 1:30 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

 

Try  "  char instead of  '  (char 39). I never use  '  under Windows. 

 

Best regards

Sandro Cumerlato 

 

On 22 Mar 2017 23:47, "James Richters" mailto:ja...@productionautomation.net> > wrote:

I'm trying to use copyfile and cannot get it to work,  anyone have any ideas?

I'm using the procedure below.  My writeln showing the contents of the 
variables seems to indicate they are correct.  The souce file does exist and is 
correct, the destination file does not exitst.
I get an error 50 which is

ERROR_NOT_SUPPORTED  50 (0x32)
The request is not supported.

I don't see how copying a file I just created is not supported.  Does anyone 
have any ideas how to get this to work or what I may be doing wrong, or if 
there is a better way I should be copying my file?   I've tried using single 
quotes and double quotes around the file names.

Thanks

James


Uses
   Serial,Windows,jwanative,sysutils;

Procedure Copy_Backup_Rename(CBR_Filename:String);
var
  fileSource, fileDest: string;
  resultsofit : Boolean;

Begin
   fileSource := chr(39)+Prog_Drive+Prog_Path+'\'+CBR_Filename+'.tmp'+chr(39);
   fileDest := chr(39)+'C:'+Prog_Path+'\'+CBR_Filename+'.temp'+chr(39);
   writeln (filesource+''+filedest);
   resultsofit := CopyFile(PChar(fileSource), PChar(fileDest), False);
   writeln (resultsofit);
   writeln(getlasterror);
End;

Console output:
'C:\ProMill\BitTool.tmp''C:\ProMill\BitTool.temp'
FALSE
50

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
<mailto:fpc-pascal@lists.freepascal.org> 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] outtextXY not moving pointer

[James Richters]

I am using a combination of outtext and outtextxy for an application using
the graph unit on Windows.  I am noticing that outtextxy is not moving the
pointer to the end of text as it is supposed to.   Outtext does move the
pointer, outtextxy is not moving the pointer.

The documentation here:
http://www.math.uni-leipzig.de/pool/tuts/FreePascal/units/node9.html#pro:Out
Text

And here : https://www.freepascal.org/docs-html/rtl/graph/outtextxy.html  

 

states that both outtext and outtextxy are supposed to move the current
position to the end of the text.   

 

Any idea's why this is not working or how to get it fixed?

 

Jim

 


8.4.50 OutText 


Declaration 

Procedure OutText (Const TextString : String); 

Description 

OutText puts TextString on the screen, at the current pointer position,
using the current font and text settings. The current position is moved to
the end of the text. 

Errors 

None. 

See also 

OutTextXY
 



8.4.51 OutTextXY 


Declaration 

Procedure OutTextXY (X,Y : Integer; Const TextString : String); 

Description 

OutText puts TextString on the screen, at position (X,Y), using the current
font and text settings. The current position is moved to the end of the
text. 

Errors 

None. 

See also 

OutText
 

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FPC Graphics options?

[James Richters]

I have a few console graphics applications that I originally wrote in Turbo
Pascal that I have been able to convert over to Free Pascal and now have
windows versions of these programs.  I notice that unless I run my program
on a 3.5GHz machine or faster, the graphics are fairly slow.By slow, I
mean noticeably slower than they were on a Pentium 233 DOS machine with
Turbo Pascal.  The intended computers for these programs are simple
inexpensive PCs with motherboard video, no dedicated video cards, I think it
should be possible for any modern computer to severely out perform a Pentium
233 with a VGA card in it, so I'm not sure what the issue is.   I am just
using the graph unit for windows, and I wonder if there is a more efficient
method of creating a full screen graphics only application than to use the
graph unit?I am only looking for it to work under windows and the main
issue I would like to solve is the speed of drawing things on the screen
like lines and arcs.  It would be nice if I am also able to get away from
BGI fonts and use True Type fonts instead.  I don't need 3D rendering or
anything so complicated, just to draw lines and arcs and maybe ellipses as
well as various text, and flood fill closed shapes with some solid color.

 

Any Suggestions? 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thanks for the help and advice with this.  I've been trying to figure out how a 
lot of this works.  Here's where I'm at

>You could try the units ptcgraph or sdlgraph as alternatives (both are part of 
>FPC).

These seemed like the easiest things to start with.

ptcgraph: I'm having 2 issues trying ptcgraph,  1, I can't seem to get it 
to be completely full screen 1280x1024 seems to be the largest I can make it.   
2, The graphics window created by ptcgraph does not respond with wincrt.  

Sdlgraph:I have not been able to successfully execute with SDLgraph, I can 
compile it, but when I try to run it I get "The application was unable to start 
correctly (0xc07b) Click Ok to close the Application"  I have no idea what 
this even means or how to do anything about it... maybe I am missing some 
component to use sdlgraph

>Porting them to Lazarus (GUI) is not an option?
I have tried to port to Lazarus but that would be a monumental task, these are 
not little programs, they are over 25,000 lines of code and to change the 
project over to a windows GUI would require an entire re-write which I don't 
have time for.   A Console application with using graph and wincrt is suitable 
for everything else but I just have this screen performance issue

>   I'm not saying this is your performance problem (especially comparing
>   a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another
>   problem contributing to your speed issue.

This may be a general processing issue and I'm just noticing it on screen 
performance.   The target computers for this application are 64bit windows 10 
PC's with integrated graphics on motherboard (no separate GPU), however I am 
running with win32 because I cannot figure out how to compile my console 
application to be a 64bit application.  I have installed 
'fpc-3.0.2.i386-win32.cross.x86_64-win64.exe'  but I don't see any fp.exe to 
run so I'm a bit lost with it.  

>  I highly recommend you take a look as AggPas. It is a 100% high
>  quality sub-pixel rendering engine

AggPas looks awesome, but can I use it with my console application?  I 
downloaded it and can't even run the sample programs included with it.. maybe 
they are Delphi examples or something?  I think I'm a bit over my head with 
that unless I can find an example of how to make a console application with it.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FPC 64bit for windows

[James Richters]

I am wondering if it's possible to compile my windows console app
specifically for 64bit machines running windows?  I am currently compiling
it as a win32 console application because I cannot figure out how to compile
it as a 64bit program.  I normally run bin\i386-win32\FP.EXE and use the
text based IDE to compile my program.   When I try to install 64 bit windows
version, I don't have this anymore, is It possible to use the text based IDE
to compile 64 bit programs or do I need to learn how to do it from the
command line?   Any advice is appreciated

 

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thank you for the console example.  I really don't have anything too 
complicated, just basic 1 pixel wide lines, arcs and simple text the most 
complex shapes are outlines of ellipses. I don't have any surfaces or textures 
or anything really complicated.  I did appreciate how much better 1 pixel wide 
lines and curves appear with the anti-aliasing and sub-pixel accuracy provides.



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 7:33 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 11:51, James Richters wrote:
ication to be a 64bit
> application.  I have installed
> 'fpc-3.0.2.i386-win32.cross.x86_64-win64.exe'  but I don't see any 
> fp.exe to run so I'm a bit lost with it.

Yes, I don't know why the Free Pascal team doesn't make official 64-bit 
versions of FPC. I always end up having to compile my own full 64-bit FPC - 
which is very easy by the way.


> AggPas looks awesome, but can I use it with my console application?

Yes, you definitely can. I use AggPas in multiple headless servers too as 
console or CGI applications.


> I downloaded it and can't even run the sample programs included with
> it.. maybe they are Delphi examples or something?

Correct, unfortunately the demos are all GUI based demos at this time, 
but any of the actual drawing code inside those demos will be exactly 
the same for a console application.

Probably the easiest way to get your feet wet with AggPas is to use the 
agg_2D.pas (for non-GUI apps) unit. It doesn't give you the full power 
of AggPas, but presents you with a Agg2D object where you simply need to 
make graphic drawing method calls.

For example:
   // Star shape
   agg^.LineCap(CapRound);
   agg^.LineWidth(5);
   agg^.LineColor($32 ,$cd ,$32 );
   c1.Construct(0, 0 , 255, 200);
   c2.Construct(0, 0, 255, 50);
   agg^.FillLinearGradient(100, 100, 150, 150, c1, c2);
   agg^.Star(100 ,150 ,30 ,70 ,55 ,5 );


Attached is a console app example using the agg_2D.pas unit. It also 
uses the FPImage units (included with FPC) to generate a "test.png" 
image as output. You could use Memory Images too, depending on your 
application needs.

Compile the example with the following command

   $ fpc -FUunits -Fu../ -Fi../ Agg2DConsole.dpr

Adjust the -Fu and -Fi paths to match your environment, or simply save 
the Agg2DConsole.dpr into the "agg-demos" directory and compile with the 
above command.



Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I am trying to run your sample program.  I am able to compile it, but when I 
try to run it I get:

Agg2dconsole.exe - System Error
The Program can't start because freetype.dll is missing from your computer. Try 
reinstalling the program to fix the problem

Any ideas?


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 10:52 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 15:45, James Richters wrote:
> I did appreciate how much better 1 pixel wide lines and curves appear 
> with the anti-aliasing and sub-pixel accuracy provides.

Indeed, AGG (and AggPas) does a fantastic job and high quality line and text 
rendering with sub-pixel accuracy.

Here is the output of a fpGUI + AggPas example. Everything seen, is rendered 
via AggPas’s API - no bitmaps have been used.

   http://fpgui.sourceforge.net/images/full/fpgui_agg-powered.png


Anyway, I hope you find a suitable solution to your problem. I think you have 
ample choice now. ;-)

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

I'm not quite following your batch file.  I have no 'src' directory, where is 
that supposed to be?

Here is where I am at:
I have just downloaded your repo at https://github.com/graemeg/freepascal  and 
I have it saved at 'J:\Programming\FreePascal'   Is there a better place to 
download the x86 64bit source?

My existing 32bit freepascal compiler I have been using is installed at 
'J:\Programming\FPCWin' I believe it's V3.0.0

What directory do I put 'go.bat' 
Where am I setting Install_prefix?  Is that where I put the source code or 
where I want the compiled version to go?

Thanks for the help!

Jim


=[ go.bat ]
set TARGET=x86_64-win64
set COMPILER=J:\Programming\FPCwin\fpc.exe
set NEWFPC=3.0.2

cd src
make clean

make all FPC=%COMPILER%
rem OPT="-Fl/usr/local/lib"

make install INSTALL_PREFIX=c:\lazarus\fpc\%NEWFPC%\%TARGET% FPC=%COMPILER%
cd ..
==

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 7:41 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-15 11:59, James Richters wrote:
> When I try to install 64 bit windows
> version, I don't have this anymore

The Free Pascal project, for some weird reason, only ships a 64-bit Windows 
cross-compiler. So you need both the 32-bit and 64-bit installs. 
I don't know why they do this.

Simply compile your own _full_ 64-bit FPC, by installing a previous or current 
stable 32-bit release. Download the latest stable release source code. And then 
build a new 64-bit target compiler and tools.

It might sound complicate, but the process is pretty easy. Here is a batch file 
I normally use to do this for me.


=[ go.bat ]
set TARGET=x86_64-win64
set COMPILER=c:\lazarus\fpc\2.6.2\bin\x86_64-win64\fpc.exe
set NEWFPC=2.6.4

cd src
make clean

make all FPC=%COMPILER%
rem OPT="-Fl/usr/local/lib"

make install INSTALL_PREFIX=c:\lazarus\fpc\%NEWFPC%\%TARGET% FPC=%COMPILER%

cd ..
==

Adjust the paths and versions to match your environment.

But again, I don't know why the FPC team doesn't make an official full 
64-bit Windows release??

Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

> If you want the FPC 3.0.2 version, then download the official source archive 
> for the 3.0.2 release from FPC's SourceForge page.

Could you please give me a link to download 3.0.2 source archive?  I'm on 
the FPC sourceforge page but I'm very confused as to what is what.



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 12:18 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-15 16:57, James Richters wrote:
> I'm not quite following your batch file.  I have no 'src' directory, 
> where is that supposed to be?

If you want the FPC 3.0.2 version, then download the official source archive 
for the 3.0.2 release from FPC's SourceForge page.


> Here is where I am at: I have just downloaded your repo at
> https://github.com/graemeg/freepascal  and I have it saved at

That repo only tracks the Trunk (unstable) branch. So if you want the 
source code of a stable release, download the archive from SourceForge.

> 'J:\Programming\FreePascal'   Is there a better place to download the
> x86 64bit source?

I normally order my directories as follows:

   c:\FPC
\2.6.4\
   \src
   \i386-win32
  \bin
  \lib
  \share
   \x86_64-win64
  \bin
  \lib
  \share
\3.0.2\
   \src
   \i386-win32
  \bin
  \lib
  \share
   \x86_64-win64
  \bin
  \lib
  \share

So a source archive will be unpacked in the correct "src" directory. 
This setup also allows me to have a single global fpc.cfg file for all 
FPC versions. The paths in that fpc.cfg file uses FPC's macros to expand 
to the correct versions.

My Linux and FreeBSD systems have a similar layout.


> What directory do I put 'go.bat'

It will go in the c:\fpc\\ directory.  But it doesn't really 
matter, as long as you adjust the paths inside the patch file to match 
your environment.


  Where am I setting Install_prefix?
> Is that where I put the source code or where I want the compiled
> version to go?

That's where the new compiled version will go. So if you use FPC 2.6.4 
to build a new 3.0.0 compiler, then the install prefix will translate to 
the path:  c:\fpc\3.0.0\x86_64-win64\


Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

Thank you for pointing me in the right direction.  I was trying to go to 
Windows instead of source, so I was lost

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 1:57 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-15 18:19, James Richters wrote:
> Could you please give me a link to download 3.0.2 source archive?
> I'm on the FPC sourceforge page but I'm very confused as to what is 
> what.


All downloads can be found from here:

   https://sourceforge.net/projects/freepascal/files/

 From there you click "Source" and then "3.0.2".  ;)

   https://sourceforge.net/projects/freepascal/files/Source/3.0.2/

For Windows you probably want the .zip file so look for:

fpc-3.0.2.source.zip

For Linux/FreeBSD/*nix you probably want the .tar.gz file so look for:

fpc-3.0.2.source.tar.gz

But in actual fact, the FPC compiler will compile either of them without 
problems. I ofter share a source archive between my Linux and Windows VMs.


Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I put freetype.dll in with the sample program and I was able to successfully 
compile it, and I can even run it without any errors, but I never get any 
graphics display.. am I missing some obvious step?I am compiling and 
running it with the Free Pascal text mode IDE, I added the paths to aggpas to 
my directories so it is finding them and using them.  I can trace into the 
program and I see it is going into aggpas units, but I do not get any graphical 
window, I don't get any errors either, it just runs and exits.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 11:57 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 16:28, James Richters wrote:
> Agg2dconsole.exe - System Error The Program can't start because 
> freetype.dll is missing from your computer. Try reinstalling the 
> program to fix the problem
>
> Any ideas?

Sorry about that. AggPas uses the FreeType library (preferred - more features 
that GDI) or Windows GDI for font support. Seeing as that demo doesn't output 
text, I really should have disabled font support via

   {$DEFINE AGG2D_NO_FONT}

at the top of the unit, but I forgot to do that. So, you can do the above and 
recompile or...

Alternatively, simply copy the freetype.dll into the same directory as the 
executable, or in your Windows System path. You can find a copy included with 
fpGUI's code repository in a ZIP file located at:

   /extras/freetype_windows/freetype.zip



Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thank you, I will try that version and also change to ptcgraph.

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Monday, May 15, 2017 4:32 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/15/2017 11:25 PM, Nikolay Nikolov wrote:
>
>
> On 05/15/2017 01:51 PM, James Richters wrote:
>> Thanks for the help and advice with this. I've been trying to figure 
>> out how a lot of this works.  Here's where I'm at
>>
>>> You could try the units ptcgraph or sdlgraph as alternatives (both 
>>> are part of FPC).
>> These seemed like the easiest things to start with.
>>
>> ptcgraph: I'm having 2 issues trying ptcgraph,  1, I can't seem 
>> to get it to be completely full screen 1280x1024 seems to be the 
>> largest I can make it.   2, The graphics window created by ptcgraph 
>> does not respond with wincrt.
> 1. use ptcgraph from fpc trunk, that supports resolutions higher than
> 1280x1024
Sorry, I still haven't updated it in fpc trunk. Use the trunk version from the 
ptcpas sourceforge repo:

https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I have managed to get ptcgraph and ptccrt to work with my program and I can 
report that there is an AMAZING increase in graphics performance!   It is 
pretty much a drop in replacement and I did not change any compiler settings.  
I did have to make a few minor changes to get it to work, not enough to change 
the speed of anything.

I am getting an error 217 access violation when I try to use outtextXY after a  
SetTextJustify(2,2);  (Top, Right justify)  but with the graph unit my text was 
in the correct place and not off the screen.

I also no longer have the 'graphwindow' handle variable so I had to comment out 
anything that was using it like

SetWindowTextA(graphicwindow,graphwindowtext);
And 
ShowWindow(graphwindow, SW_SHOW);
So I just commented them out for now.I'm hoping there is a way to get 
around the graphwindow variable because I was using the above 2 functions and I 
don't know how else to determine the graphic window handle... but the 
performance gain and ease of implementation will make working out any other 
issues worth the effort.  Any advice on how I can capture the graph window 
handle would be appreciated

Thank you for the help with this.

Jim

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
nore...@z505.com
Sent: Monday, May 15, 2017 5:50 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 01:02, Sven Barth via fpc-pascal wrote:
>>> Wow, Graeme! That's harsh. One of the last set of benchmarks I did 
>>> that focused on integer math and procedure call speed came out as
>>> follows:
>> 
>> 
>> I think he specifically meant graphics apps, not general apps
> 
> While a raytracer is indeed a graphics app it's mainly about CPU 
> computation in this case and not interfacing with the GPU like OpenGL 
> does (of course one can write a raytracer to take advantage of the 
> parallel architecture of a GPU, but that's bot the case in this 
> specific example).
> 


Graeme will need to clarify whether he was trying to be harsh on FPC entirely, 
or just specifically in some areas.. :-)

But Nikolay Nikolov's replacement unit should tell if fpc is as fast as 
turbopascal, as he claims it is a direct replacement and is super fast Then 
it's not fpc's fault but some problem in the default unit that was not 
optimized?  I don't know, never tried Nikolay's unit. But that also depends on 
whether Graeme was using that code from that unit too.

Any claims that something is slow depends entirely on 1 million parameters...
Then there are even those projects out there like FastMM but that's probably 
another aside unrelated ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Yes, I did get the test.png file..  I understand the concept now.  Aggpas 
figures out what the status of the pixels should be then you update the screen 
with those pixels.

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 6:05 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 20:50, James Richters wrote:
> see it is going into aggpas units, but I do not get any graphical 
> window, I don't get any errors either, it just runs and exits.

The example is a pure console application with no output to any display. 
Instead it generates a "test.png" file as its output. If you ran the 
Agg2DConsole binary from a command line, there should be a "test.png" 
image in that same directory.

As I mentioned, AggPas can use allocated memory, array, a memory image etc as 
its rendering buffer. If you want a graphical console program
(eg: using Linux Console Framebuffer) using AggPas, then render your 
application output via AggPas to a memory image, then bitblit that image to the 
console graphics output in whatever paint event you have available.

Using AggPas with desktop GUI applications works pretty much identical as 
above, except it bitblit's the memory image to the Window Canvas.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thank you for the explanation.  For now I can live without the windows API 
calls,  It does work to manually switch back and forth to the text console 
window, and I'm really the only one who does that as I sometimes perform some 
diagnostic functions in there.  The performance gains are worth it.   

Is there a way to just turn off the windows title bar when the window is 
created, or change the initial name of the window?

I'll just stick with my BGI fonts for now, if I want to move into true type 
fonts I'll look into doing something as  you suggest with the buffer.

I did figure out what my 217 error was,  it just happened to be the only time I 
right justified something, but it was actually in a unit where I neglected to 
change graph to ptcgraph, and that caused the error.

Thanks again for the help, this is a great quick fix and huge performance gain.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Monday, May 15, 2017 8:46 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/16/2017 01:37 AM, James Richters wrote:
> I have managed to get ptcgraph and ptccrt to work with my program and I can 
> report that there is an AMAZING increase in graphics performance!   It is 
> pretty much a drop in replacement and I did not change any compiler settings. 
>  I did have to make a few minor changes to get it to work, not enough to 
> change the speed of anything.
>
> I am getting an error 217 access violation when I try to use outtextXY after 
> a  SetTextJustify(2,2);  (Top, Right justify)  but with the graph unit my 
> text was in the correct place and not off the screen.
Can you send me a small program that demonstrates the problem, so I can try to 
reproduce it and fix it?
>
> I also no longer have the 'graphwindow' handle variable so I had to 
> comment out anything that was using it like
>
> SetWindowTextA(graphicwindow,graphwindowtext);
> And
> ShowWindow(graphwindow, SW_SHOW);
> So I just commented them out for now.I'm hoping there is a way to get 
> around the graphwindow variable because I was using the above 2 functions and 
> I don't know how else to determine the graphic window handle... but the 
> performance gain and ease of implementation will make working out any other 
> issues worth the effort.  Any advice on how I can capture the graph window 
> handle would be appreciated
Unfortunately, you can't do that and it's actually the main reason why ptcgraph 
is fast. Even if you modify the ptcgraph source, so that you get the window 
handle, it would do you no good, because the window is created in a different 
thread and this means that you cannot draw to the window from your program's 
thread. In fact, all the ptcgraph drawing routines actually render to an 
internal software buffer and issue no winapi drawing calls at all. That's the 
reason ptcgraph is fast and the regular graph unit is slow - the winapi drawing 
routines are really the bottleneck in this case and not the speed of the code, 
generated by FPC.

I know this is not ideal, but probably the easiest option is to find a suitable 
bgi .chr font pack or try a ttf to .chr conversion tool. If you own a copy of 
Turbo Pascal (or Turbo C/C++), you can use the .chr fonts that came with it. 
Unfortunately, other solutions are hard - they involve e.g. linking the 
freetype library, using it to render to a software buffer, and then blitting 
this buffer to the ptcgraph canvas with PutImage. Or doing a similar thing with 
winapi functions, but by drawing the text on a DIB (device independent bitmap, 
basically a memory buffer, holding an image) that you created, instead of on 
the window directly, then reading from the DIB and blitting it with PutImage 
once again.

Best regards,
Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

> Hmm? But he only wants to change the title of the window. Even on Windows 
> that should work from a different thread. However a platform independent 
> SetWindowTitle() for ptcgraph would be rather useful I guess.

I did a quick test and ran one program that did a writeln of it’s handle, then 
put that handle in another program and ran it and I was able to change the 
window title of the first program with the second program.   So if ptcgraph 
also had the graphwindow : handle variable I think it would work.

 

>Though I'd like to know why he needs ShowWindow()...

 

My application is purposefully designed not to use a mouse…  It’s CNC control 
software and mice, even optical ones out in dusty shops are tedious and 
difficult… it’s often difficult to even find a place to put a mouse, nevermind 
seeing a pointer when the screen is full of sawdust.   So I have keyboard 
commands that get me back to the console window where I can look at some things 
like the contents of some variables, then when I’m done I hit another key and 
it puts me back on the graphics window.   I just use both crt and pctcrt  and 
do things like crt.readkey and pctcrt.readkey to know which screen got the 
input.   I can get by without ShowWindow() because I can alt-tab between the 
windows without a mouse, and admittedly there isn’t a huge use for the console 
window, but it is a lot nicer for the program to put the correct window on top 
by itself.

 

It would be nice if I could: 

1.  The above mentioned ShowWindow()
2.  Make the graph window full screen always, it normally does not come up 
full screen it’s the correct size for full screen but mispositioned.. I can 
probably fix this in a shortcut that starts it but would be nice if the program 
itself forced full screen
3.  Get rid of the windows titlebar all together, I could just draw my own. 
  I was able to shut the title bar off with the graph unit, but the window 
would still be the size of the screen minus the bar.   I believe if the 
titlebar was defined to be shut off before the window was created, or shortly 
after then I could have completely full screen with no title bar. But I don’t 
know where or how the window is created to do that.
4.  If I can’t get rid of the titlebar, then setting a custom window title 
would be nice, preferably after my program was running so I could put status 
information up there, but if not possible then a one time custom title bar name 
would be great.

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Sven Barth via fpc-pascal
Sent: Tuesday, May 16, 2017 2:00 AM
To: FPC-Pascal users discussions 
Cc: Sven Barth 
Subject: Re: [fpc-pascal] FPC Graphics options?

 

Am 16.05.2017 02:46 schrieb "Nikolay Nikolov" mailto:nick...@gmail.com> >:
>> I also no longer have the 'graphwindow' handle variable so I had to comment 
>> out anything that was using it like
>>
>> SetWindowTextA(graphicwindow,graphwindowtext);
>> And
>> ShowWindow(graphwindow, SW_SHOW);
>> So I just commented them out for now.I'm hoping there is a way to get 
>> around the graphwindow variable because I was using the above 2 functions 
>> and I don't know how else to determine the graphic window handle... but the 
>> performance gain and ease of implementation will make working out any other 
>> issues worth the effort.  Any advice on how I can capture the graph window 
>> handle would be appreciated
>
> Unfortunately, you can't do that and it's actually the main reason why 
> ptcgraph is fast. Even if you modify the ptcgraph source, so that you get the 
> window handle, it would do you no good, because the window is created in a 
> different thread and this means that you cannot draw to the window from your 
> program's thread. In fact, all the ptcgraph drawing routines actually render 
> to an internal software buffer and issue no winapi drawing calls at all. 
> That's the reason ptcgraph is fast and the regular graph unit is slow - the 
> winapi drawing routines are really the bottleneck in this case and not the 
> speed of the code, generated by FPC.

Hmm? But he only wants to change the tttle of the window. Even on Windows that 
should work from a different thread. However a platform independent 
SetWindowTitle() for ptcgraph would be rather useful I guess.

Though I'd like to know why he needs ShowWindow()...

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

>Yes, you can do this, if you set:

>  FullscreenGraph := true;

 

I tried this and it does make a full screen graphics window without the windows 
title bar on top, which I like, however if I task switch out of the graphics 
window, then task switch back to it, my keyboard no longer responds via ptccrt. 
 I do this quite often, even launching things from within my program that I 
expect to be on top of it, for example I will launch a text editor and wait for 
it to be closed before my program continues.  

 

For non-full screen use, are there any variable I can set that would specify 
the graph windows position on the screen, or force the window to be maximized?

 

I was able to switch back and forth to the ptcgraph window by doing the 
following:

  {$H+}

   SetConsoleTitle(ConsoleTitle); //Change name of Console window so it’s not 
the same as the graph window

   Sleep(60); //give windows some time to make the change

   GraphWindow:=FindWindow(nil,Pchar(paramstr(0)+#0#0));  //Figure out handle 
for graph window with FindWindow()

  // the following all work with the handle obtained for the ptcgraph window 
with the above method

   setwindowtextA(graphwindow,GraphTitle); 

   ShowWindow(graphwindow,SW_show);

   SetActiveWindow(graphwindow);

   SetForegroundWindow(graphwindow); 

 

It would be handy if GraphWindow was set to the ptcgraph window handle to make 
it compatible with the graph unit

 

Thanks for the help with this, I really appreciate it

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 16, 2017 7:45 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

 

 

 

On 05/16/2017 01:27 PM, James Richters wrote:

> Hmm? But he only wants to change the title of the window. Even on Windows 
> that should work from a different thread. However a platform independent 
> SetWindowTitle() for ptcgraph would be rather useful I guess.

I did a quick test and ran one program that did a writeln of it’s handle, then 
put that handle in another program and ran it and I was able to change the 
window title of the first program with the second program.   So if ptcgraph 
also had the graphwindow : handle variable I think it would work.

 

>Though I'd like to know why he needs ShowWindow()...

 

My application is purposefully designed not to use a mouse…  It’s CNC control 
software and mice, even optical ones out in dusty shops are tedious and 
difficult… it’s often difficult to even find a place to put a mouse, nevermind 
seeing a pointer when the screen is full of sawdust.   So I have keyboard 
commands that get me back to the console window where I can look at some things 
like the contents of some variables, then when I’m done I hit another key and 
it puts me back on the graphics window.   I just use both crt and pctcrt  and 
do things like crt.readkey and pctcrt.readkey to know which screen got the 
input.   I can get by without ShowWindow() because I can alt-tab between the 
windows without a mouse, and admittedly there isn’t a huge use for the console 
window, but it is a lot nicer for the program to put the correct window on top 
by itself.

 

It would be nice if I could: 

1.  The above mentioned ShowWindow()
2.  Make the graph window full screen always, it normally does not come up 
full screen it’s the correct size for full screen but mispositioned.. I can 
probably fix this in a shortcut that starts it but would be nice if the program 
itself forced full screen

Yes, you can do this, if you set:

  FullscreenGraph := true;

In the beginning of your program (before InitGraph). Tonight I'll also add the 
option for changing the title bar text, when in windowed mode.



3.   
4.  Get rid of the windows titlebar all together, I could just draw my own. 
  I was able to shut the title bar off with the graph unit, but the window 
would still be the size of the screen minus the bar.   I believe if the 
titlebar was defined to be shut off before the window was created, or shortly 
after then I could have completely full screen with no title bar. But I don’t 
know where or how the window is created to do that.
5.  If I can’t get rid of the titlebar, then setting a custom window title 
would be nice, preferably after my program was running so I could put status 
information up there, but if not possible then a one time custom title bar name 
would be great.

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Sven Barth via fpc-pascal
Sent: Tuesday, May 16, 2017 2:00 AM
To: FPC-Pascal users discussions  <mailto:fpc-pascal@lists.freepascal.org> 

Cc: Sven Barth  <mailto:pascaldra...@googlemail.com> 

Subject: Re: [fpc-pascal] FPC Graphics options?

 

Am 16.05.2017 02:46 schrieb "Nikolay Nikolov" mailto:nick...@gmail.com> >:
>> I also no longer have the 'graphwi

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Join the bad time estimate club! The help is very much appreciated and 
whatever time you can allow for it great.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 16, 2017 5:42 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/16/2017 02:45 PM, Nikolay Nikolov wrote:
>
>
> Tonight I'll also add the option for changing the title bar text, when 
> in windowed mode.
Unfortunately, I didn't have the time to do it tonight (I'm kinda bad at time 
estimates ;-) ), but I'll probably implement it during the weekend.

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] ptcgraph issues

[James Richters]

I'm having a few issues with ptcgraph.  

 

The main issue is that it's not correctly reporting the actual size of the
available area to use inside the ptcgraph window.  It's reporting my full
screen resolution, but that amount of space is not really available due to
the title bar.   The window that is generated is a 1919x1176 window, but it
won't fit on the screen due to the title bar, so I hit maximize, now it fits
on the screen but it's too small.   I generate my screen based off the
GetMaxX and GetMaxY functions and my screen based on GetMaxX being 1919 and
GetMaxY being 1199 should not fit inside a window that fills the screen but
with a border around it and a title bar at the top, but it is being scaled
down to fit.  This scaling is causing pixels to be dropped.   If I force
GetMaxX and GetMaxY to be the correct numbers of 1919x1176 which is what the
graph unit reports, It just leaves a gap at the bottom of the screen the
same width as the title bar, and still scales the screen from 1919x1199 down
to fit in the available space of 1919x1176 making some pixels drop.I
have tried maximizing the screen with ShowWindow(graphwindow, SW_Maximize);
before I use GetMaxX and GetMaxY, but they still report the full screen
size.   

 I can get the screen to look right with no scaling and no dropped pixels if
I use SetWindowPos(Graphicwindow,HWND_TOP,-8,-32,0,0,swp_nosize); to
position the window so the title bar is off the top of the screen,  but as
you can see my X and Y coordinates are screwy. it's something to do with my
multiple monitors why top left is not 0,0  So I have no way of knowing what
to set this to on any given system, so it's not really a solution at all. it
just proves what the problem is.

 

So I thought I would force it to be full screen, to see if I could prevent
the scaling.. but that also has issues.  I figured if it looks right
shifting the title bar off the top of the screen, then simply shutting off
the title bar should fix it, but I could not get that to work either.  There
are 2 ways I can get full screen without the title bar that I can think of.
I can just shut off all windows styles withSetWindowLongPTR(graphwindow,
GWL_STYLE, 0);   but this has the opposite problem,  If I draw a rectangle
from 0,0 to GetMaxX,GetMaxY, I should get a rectangle that barely fits on
the screen, but I don't see anything because it's way too big.  I have to
draw a rectangle from 8,8 to GetMaxX-8,GetMaxY-8 to get it to fit on the
screen.However with this method of getting rid of the titlebar, I can
taskswitch out and back in with no issues, my keyboard still works and if I
taskswitch out, it just puts other windows on top of this, so I can always
click on it to make it active again.  The scaling causes things to not look
right.

 

 

If I get the full screen by setting fullscreengraph := True;  then it does
seem to report stop scaling and now everything fits correctly on the screen,
however. this has it's own issues.   For some reason when I use this to
obtain full screen, it does not task switch anywhere near as gracefully as
using SetWindowLongPTR(graphwindow, GWL_STYLE, 0);If I task switch to
anything else, the graph window disappears completely, so now I have nothing
to click on to get it back, and using ShowWindow() to get it back takes a
very long time.  Then when I eventually get the window back, it no longer
responds to the keyboard. 

 

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

I still haven't figured out how to do this.  Is there an easier way to generate 
a 64bit executable for windows than to compile this myself?

I've downloaded fpc-3.0.2.source.zip but I think I'm still not getting the 
directories right or something.   Are there instructions somewhere on how to do 
this?

When I try to do the "Make Clean"  I get
Makefile:29: *** You need the GNU utils package to use this Makefile.  Stop.

I think I am missing something somehow.

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 1:57 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-15 18:19, James Richters wrote:
> Could you please give me a link to download 3.0.2 source archive?
> I'm on the FPC sourceforge page but I'm very confused as to what is 
> what.


All downloads can be found from here:

   https://sourceforge.net/projects/freepascal/files/

 From there you click "Source" and then "3.0.2".  ;)

   https://sourceforge.net/projects/freepascal/files/Source/3.0.2/

For Windows you probably want the .zip file so look for:

fpc-3.0.2.source.zip

For Linux/FreeBSD/*nix you probably want the .tar.gz file so look for:

fpc-3.0.2.source.tar.gz

But in actual fact, the FPC compiler will compile either of them without 
problems. I ofter share a source archive between my Linux and Windows VMs.


Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

That would be very much appreciated, I don't know why I have such difficulty 
with this.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Thursday, May 18, 2017 6:02 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-18 22:53, James Richters wrote:
> Is there an easier way to generate a 64bit executable for windows than to 
> compile this myself?

I can zip up my 64-bit FPC 3.0.2 directory and make it available for 
_unofficial_ download if that will help. Let me know, and I'll post a link to 
the download.

Regards,
   Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

Thank you for the explanation.  I didn't really understand how to use the cross 
compiler.

I have installed the cross compiler and tried to compile my program with 

ppcrossx64 program.pas

but I get
PaStep.pas(3,98) Fatal: Can't find unit smtpsend used by PAStep

Smtpsend is part of synapse...   I was going to try to copy the library to the 
x86_64-win64 folder but then I thought, wait a minute, I will need the 64bit 
library to get this to work...  but it looks to me like Synapse has only 
support for Win32.  So maybe I'm out of luck with a 64bit version if I'm going 
to use Synapse, unless the cross compiler will take care of this for me?  
Anyone know about this?   

I'm not sure I really need to compile a 64bit version for any reason, it's just 
I don't plan to ever run the program on a 32bit machine, so I'm thinking if I 
have a 64bit machine I might as well have a 64bit program as well and thought 
it might offer a performance advantage.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Thursday, May 18, 2017 7:39 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows



On 05/15/2017 02:41 PM, Graeme Geldenhuys wrote:
> On 2017-05-15 11:59, James Richters wrote:
>> When I try to install 64 bit windows
>> version, I don't have this anymore
>
> The Free Pascal project, for some weird reason, only ships a 64-bit 
> Windows cross-compiler. So you need both the 32-bit and 64-bit 
> installs. I don't know why they do this.
Is there an _actual_ problem with that, or is it only imaginary? The
32-to-64 crosscompiler works perfectly fine and has no known disadvantages. On 
the other hand, the 64-bit compiler cannot crosscompile 32-bit fpc, because it 
doesn't support the 80-bit extended float type, which is only supported by the 
x87 FPU, but not by SSE. So, basically, if you're a FPC compiler developer and 
you're using windows as your main platform, the 64-bit native fpc is inferior. 
And I don't think anyone has a problem running a 32-bit hosted compiler on a 
64-bit windows OS - there are simply no known issues with that under any 64-bit 
windows version that I know of.
>
> Simply compile your own _full_ 64-bit FPC, by installing a previous or 
> current stable 32-bit release. Download the latest stable release 
> source code. And then build a new 64-bit target compiler and tools.
Or, alternatively, you can simply install the 32-bit to 64-bit crosscompiler on 
top of your already working install and then crosscompile from the commandline 
with:

  ppcrossx64 program.pas

without any need to compile fpc from sources. It won't work from the IDE, 
though, but compiling your program from the command line, when you want to 
build a 64-bit .exe shouldn't be hard.

Of course, there's no problem in following Graeme's route and compiling the 
compiler yourself (and it might be helpful in the long run to learn how to 
compile the compiler), but installing the already packaged
32-to-64 crosscompiler package might be easier to start with.
>
> It might sound complicate, but the process is pretty easy. Here is a 
> batch file I normally use to do this for me.
>
>
> ...
>
> But again, I don't know why the FPC team doesn't make an official full 
> 64-bit Windows release??
Because it is inferior, since it cannot build a 32-bit FPC. Imagine your advice 
for compiling the 64-bit native compiler, using the 32-bit starting compiler. 
What would happen if you had to go the other way around? Your advice only 
works, because the 32-bit compiler can compile both the 32-bit and 64-bit 
version of FPC. If you were to start with the 64-bit version, it won't be able 
to compile the 32-bit version (under windows, that is; under linux, it works, 
because 64-bit linux has abi support for the 80-bit extended x87 fpu type and 
there we usually ship a native 64-bit compiler). It may not matter for you, but 
is a huge showstopper for any FPC compiler developer that uses Windows.

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ptcgraph issues

[James Richters]

I've been able to figure out a few workarounds for issues with ptcgraph,

 

To prevent scaling and dropped pixels, I have come up with 3 workarounds,
not ideal but they could work:

 

1.  Positon the window so the title is off the top of the screen with

   SetWindowPos(Graphicwindow,HWND_TOP,-8,-31,0,0,SWP_NoSize);

   I cannot use maximize with this and the coordinates for the
top left corner might be different on different machines.  

   I think my development computer is strange because of having
3 monitors

 

2.  Leave the title bar on with the window sized correctly, but set my
own variables to not use the bottom of the window which

is off the screen so it looks right with

SetWindowPos(Graphicwindow,HWND_TOP,-8,0,0,0,SWP_NoSize);

WinMax_Y:=GetMaxY-31;  

   Then I use WinMax_Y instead of GetMaxY

   This has the same problem as option #1 in that the
coordinates for the top left of the screen might not be the same on other
machines

   I haven't been able to find a really good solution to keeping
the titlebar and having the window the right size and being able to use
maximize. 

   I think the only way will be for ptcgraph to create the
window sized so maximized it fits completely on the screen with the titlebar
and then report a smaller GetMaxY

 

3.  Turn off the title bar, then reset the size of the window to be
correct with:

 SetWindowLongPTR(graphicwindow, GWL_STYLE, 0);

 SetWindowPos(Graphicwindow,HWND_TOP,0,0,GetMaxX+1,GetMaxY+1,0);

 ShowWindow(graphicwindow, SW_Maximize);

If you don't want the titlebar then this is the best solution because the
Maximize will make it fit properly on the screen regardless of 

How it is configured.

 

 

The only other issue I am having is the problem where task switching with
ALT-Tab causes the keyboard not to respond to ptccrt anymore.  I have
narrowed this down a bit,  it's NOT task switching in general that causes
this, it's specifically ALT-TAB that causes it.   I was also mistaken about
it only happening with full screen, this happens all the time, no matter how
the window is configured.  If I hit the windows logo key and task switch
that way , there is no problem when I go back to the ptcgraph window, also
if I get back to my console window with 

 ShowWindow(ConsoleWindow,SW_show);

 SetActiveWindow(ConsoleWindow);

 SetForegroundWindow(ConsoleWindow);

And alt tab from the console window, then no matter what method I use to get
back to the ptcgraph window, even alt-tab,  it's no problem and ptccrt
responds to the keyboard.

 

So that's where I'm at with this.  It would be great if better solutions can
be found for these issues.  The main thing for me is the ALT-Tab issue,
especially if I go with option 3 above where I won't have a minimize button.
Alt-tab is a really big habit because as I mentioned before, most of the
computer I run this on don't have a mouse attached.   If I could disable
alt-tab from this window somehow, then at least I wouldn't accidentally
break keyboard response to the ptcgraph window, but I don't know how I could
do that either.

 

James

 

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf
Of James Richters
Sent: Wednesday, May 17, 2017 4:19 PM
To: 'FPC-Pascal users discussions' 
Subject: [fpc-pascal] ptcgraph issues

 

I'm having a few issues with ptcgraph.  

 

The main issue is that it's not correctly reporting the actual size of the
available area to use inside the ptcgraph window.  It's reporting my full
screen resolution, but that amount of space is not really available due to
the title bar.   The window that is generated is a 1919x1176 window, but it
won't fit on the screen due to the title bar, so I hit maximize, now it fits
on the screen but it's too small.   I generate my screen based off the
GetMaxX and GetMaxY functions and my screen based on GetMaxX being 1919 and
GetMaxY being 1199 should not fit inside a window that fills the screen but
with a border around it and a title bar at the top, but it is being scaled
down to fit.  This scaling is causing pixels to be dropped.   If I force
GetMaxX and GetMaxY to be the correct numbers of 1919x1176 which is what the
graph unit reports, It just leaves a gap at the bottom of the screen the
same width as the title bar, and still scales the screen from 1919x1199 down
to fit in the available space of 1919x1176 making some pixels drop.I
have tried maximizing the screen with ShowWindow(graphwindow, SW_Maximize);
before I use GetMaxX and GetMaxY, but they still report the full screen
size.   

 I can get the screen to look right with no scaling and no dropped pixels if
I use SetWindowPos(Graphicwindow,HWND_TOP,-8,-32,0,0,swp_nosize); to
position the window so the title bar is off 

Re: [fpc-pascal] ptcgraph issues

[James Richters]

Thank you Nikolay  I will give it a try and report back

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf
Of Nikolay Nikolov
Sent: Sunday, May 21, 2017 5:09 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] ptcgraph issues

 

 

 

On 05/17/2017 11:19 PM, James Richters wrote:

 

 

If I get the full screen by setting fullscreengraph := True;  then it does
seem to report stop scaling and now everything fits correctly on the screen,
however. this has it's own issues.   For some reason when I use this to
obtain full screen, it does not task switch anywhere near as gracefully as
using SetWindowLongPTR(graphwindow, GWL_STYLE, 0);If I task switch to
anything else, the graph window disappears completely, so now I have nothing
to click on to get it back, and using ShowWindow() to get it back takes a
very long time.  Then when I eventually get the window back, it no longer
responds to the keyboard. 

I just committed a fix, which might fix the issue with your program no
longer responding to the keyboard, after alt-tabbing away and then clicking
back to your application window. Can you test if r714 (ptcpas trunk in the
sourceforge repo) fixes this bug?

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

[James Richters]

Setting it before initgraph will serve my purposes just fine.  How is this 
accomplished?

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Sunday, May 21, 2017 5:47 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/16/2017 02:45 PM, Nikolay Nikolov wrote:
>   Tonight I'll also add the option for changing the title bar text, 
> when in windowed mode.
Implemented in r715. Note that you still cannot change the window title, after 
the window has been created, but at least now you can set it (in a 
multiplatform way) before InitGraph.

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

[James Richters]

I have the window title working, Thank you for that.
However I still have the same issue with non-responsive keyboard when I return 
to the graph window after an ALT-TAB.  I am running on windows 10 64bit - 
program compiled for win32.   

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Sunday, May 21, 2017 7:00 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?



On 05/22/2017 01:25 AM, James Richters wrote:
> Setting it before initgraph will serve my purposes just fine.  How is this 
> accomplished?
Just set the new WindowTitle global string variable to something, before 
calling InitGraph:

begin
   WindowTitle := 'window title goes here';
   InitGraph(...);

> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of Nikolay Nikolov
> Sent: Sunday, May 21, 2017 5:47 PM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] FPC Graphics options?
>
>
>
> On 05/16/2017 02:45 PM, Nikolay Nikolov wrote:
>>Tonight I'll also add the option for changing the title bar text, 
>> when in windowed mode.
> Implemented in r715. Note that you still cannot change the window title, 
> after the window has been created, but at least now you can set it (in a 
> multiplatform way) before InitGraph.
>
> Nikolay
Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

[James Richters]

>I cannot reproduce it on my machine after the r714 fix. Can you send me a 
>small example program, that demonstrates the problem, as well as detailed 
>steps to reproduce?

Here is a simple sample program that has the issue for me on both my windows 10 
desktop and my windows 10 laptop, both are 64bit.
https://hastebin.com/nubonozaho.pas

This is just a little program I wrote to get the ascii codes real fast off 
either the console window or graphics window.  If I recall correctly, using the 
graph unit some of the F keys were different on the graph screen than they were 
in the console screen.   This makes a good sample because it shows that the 
graph screen is responding to the keyboard, just not with what is expected.  It 
also shows that the graphic window is still actually working as well.  To 
duplicate the issue, first show that everything works as expected by switching 
between the windows by clicking on them, type some keys in each window.  Esc 
exits the program, g, G, c, & C I use to test switching windows with windows 
api calls.  

To demonstrate the problem, while on the graphics window, use alt-tab from the 
graphics window to the console window,  the keys all work as expected in the 
console window, but then if you use any method to get back to the graphics 
window, they keys reported in the graphics window are no longer correct.   
While preparing this for you I noticed that the keys reported seem to be as if 
alt is being held down when it is not and strangely, if I hold down alt and 
hit any key at all,   from that point on,  the graphic screen reacts normally 
to keystrokes.  

I will admit that I get a bit confused when it comes to manipulating units and 
things, but I'm fairly certain that I implemented r175 correctly.
I removed all copies of ptcgraph from my compiler paths and make sure I got a 
compiler error for it being not found, then put the newly compiled r175 fix in 
and compiled it. You can see I fixed my sample program to use 
Windowtitle:=Graphtitle; and that is working, so that would seem to indicate 
that I am really running r175.   

Thank you for the help with this, it is very much appreciated

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

>Here is a simple sample program that has the issue for me on both my windows 
>10 desktop and my windows 10 laptop, both are 64bit.
>https://hastebin.com/nubonozaho.pas

I started thinking about this, and did some more tests, and I think I have 
narrowed down what is really happening, but not sure how to fix it.   

The problem is not the ALT-tab from the graphics window,  it's ALT being 
pressed when the window focus changes.   CTRL is also affected, but not shift.  
Try this:
Go to Graph window,  type some letters,  see that it's working correctly,  now 
hold just ALT, or CTRL - switch to another window by clicking on it.  Click on 
console window, see letters are working correctly, now go back to graph window, 
 anything you press acts like ALT, or CTRL is still being pressed until you 
actually enter a keystroke using ALT, or CTRL.   It seems to me there is 
probably some flag or variable being set that the alt or ctrl key is being 
pressed, but is being interrupted by the window focus change, when focus is 
brought back, the variable is still set for ALT or CTRL being down, but neither 
is down anymore, but the flag cannot be cleared until a key sequence using ctrl 
or alt is used.  I did also notice that just hitting alt or ctrl and releasing 
it in the graph window clears the condition and characters are back to normal 
again.

James


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I think I figured out my problem, but I'm not sure how to fix it.   I was 
looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
And I see that the change made was to win32kbd.inc, but I don't think I'm using 
the updated version of it.   I think my problem is that I just compiled 
ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
apparently that's not the correct way to do it.So then I tried adding the 
entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/
Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now It 
can't find ptcgraph, even though it's there under  
FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
guessing and really don't have a clue the proper way to integrate this into my 
fpc compiler.

Could someone please tell me the correct way I should be doing this so that the 
compiler will find the correct versions of all the files necessary? 

James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] FPC Graphics options?

>Here is a simple sample program that has the issue for me on both my windows 
>10 desktop and my windows 10 laptop, both are 64bit.
>https://hastebin.com/nubonozaho.pas

I started thinking about this, and did some more tests, and I think I have 
narrowed down what is really happening, but not sure how to fix it.   

The problem is not the ALT-tab from the graphics window,  it's ALT being 
pressed when the window focus changes.   CTRL is also affected, but not shift.  
Try this:
Go to Graph window,  type some letters,  see that it's working correctly,  now 
hold just ALT, or CTRL - switch to another window by clicking on it.  Click on 
console window, see letters are working correctly, now go back to graph window, 
 anything you press acts like ALT, or CTRL is still being pressed until you 
actually enter a keystroke using ALT, or CTRL.   It seems to me there is 
probably some flag or variable being set that the alt or ctrl key is being 
pressed, but is being interrupted by the window focus change, when focus is 
brought back, the variable is still set for ALT or CTRL being down, but neither 
is down anymore, but the flag cannot be cleared until a key sequence using ctrl 
or alt is used.  I did also notice that just hitting alt or ctrl and releasing 
it in the graph window clears the condition and characters are back to normal 
again.

James


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I have done the "download snapshot" but I just don't know what to do with it 
now to properly integrate it into my compiler.  

Here is what I have tried to do.
First I moved everything from J:\Programming\FPC 3.0.2\units\i386-win32\graph 
to a temporary location so it wouldn't find the old versions of ptcgraph and 
ptccrt
Now when I try to compile my program, I get unit ptcgraph not found... which is 
what I want because I want to be sure not to get the old version
Then I copied the entire snapshot to into J:\Programming\FPC 
3.0.2\units\i386-win32\ptcpas
Now when I try to compile my program, I still get unit ptcgraph not found.
I added J:\Programming\FPC 3.0.2\units\$fpctarget\ptcpas\* to the directories
Now I got an error that it could not find graphh.inc 
So I copied all the .inc files from J:\Programming\FPC 
3.0.2\units\i386-win32\graph\inc to J:\Programming\FPC 
3.0.2\units\i386-win32\graph because I have no idea how else to make it find 
them.
Now I can can compile successfully and run my program, but it has the same 
issues.
But I notice the modified file win32kbd.inc is never used.   I have even 
removed it temporarily and I can still compile successfully.  I did a 
search for win32kbd and I find win32kbdd.inc but not win32kbd.inc

That is where I am at.  I think If I could correctly apply win32kbd.inc it may 
work

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 23, 2017 1:03 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 06:09 PM, James Richters wrote:
> I think I figured out my problem, but I'm not sure how to fix it.   I was 
> looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
> And I see that the change made was to win32kbd.inc, but I don't think I'm 
> using the updated version of it.   I think my problem is that I just compiled 
> ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
> apparently that's not the correct way to do it.So then I tried adding the 
> entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/
But that's a fix, that's not yet released (because it needs testing), so it's 
in svn trunk only, and not in the release files. Get it from:

  https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Either click on "Download Snapshot", or install subversion (TortoiseSVN) and 
checkout https://svn.code.sf.net/p/ptcpas/code/trunk

> Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
> ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now 
> It can't find ptcgraph, even though it's there under  
> FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
> guessing and really don't have a clue the proper way to integrate this into 
> my fpc compiler.
>
> Could someone please tell me the correct way I should be doing this so that 
> the compiler will find the correct versions of all the files necessary?
>
> James
>
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of James Richters
> Sent: Monday, May 22, 2017 7:13 PM
> To: 'FPC-Pascal users discussions' 
> Subject: Re: [fpc-pascal] FPC Graphics options?
>
>> Here is a simple sample program that has the issue for me on both my windows 
>> 10 desktop and my windows 10 laptop, both are 64bit.
>> https://hastebin.com/nubonozaho.pas
> I started thinking about this, and did some more tests, and I think I have 
> narrowed down what is really happening, but not sure how to fix it.
>
> The problem is not the ALT-tab from the graphics window,  it's ALT being 
> pressed when the window focus changes.   CTRL is also affected, but not 
> shift.  Try this:
> Go to Graph window,  type some letters,  see that it's working correctly,  
> now hold just ALT, or CTRL - switch to another window by clicking on it.  
> Click on console window, see letters are working correctly, now go back to 
> graph window,  anything you press acts like ALT, or CTRL is still being 
> pressed until you actually enter a keystroke using ALT, or CTRL.   It seems 
> to me there is probably some flag or variable being set that the alt or ctrl 
> key is being pressed, but is being interrupted by the window focus change, 
> when focus is brought back, the variable is still set for ALT or CTRL being 
> down, but neither is down anymore, but the flag cannot be cleared until a key 
> sequence using ctrl or alt is used.  I did also notice that just hitting alt 
> or ctrl and releasing it in the graph window clears the condition and 
> characters are back to norm

Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

[James Richters]

*correction  to directory names:
Now I got an error that it could not find graphh.inc So I copied all the .inc 
files from J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph\inc  to 
J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph because I have no 
idea how else to make it find them.

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Tuesday, May 23, 2017 1:29 PM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] FPC Graphics options?

I have done the "download snapshot" but I just don't know what to do with it 
now to properly integrate it into my compiler.  

Here is what I have tried to do.
First I moved everything from J:\Programming\FPC 3.0.2\units\i386-win32\graph 
to a temporary location so it wouldn't find the old versions of ptcgraph and 
ptccrt Now when I try to compile my program, I get unit ptcgraph not found... 
which is what I want because I want to be sure not to get the old version Then 
I copied the entire snapshot to into J:\Programming\FPC 
3.0.2\units\i386-win32\ptcpas Now when I try to compile my program, I still get 
unit ptcgraph not found.
I added J:\Programming\FPC 3.0.2\units\$fpctarget\ptcpas\* to the directories 
Now I got an error that it could not find graphh.inc So I copied all the .inc 
files from J:\Programming\FPC 3.0.2\units\i386-win32\graph\inc to 
J:\Programming\FPC 3.0.2\units\i386-win32\graph because I have no idea how else 
to make it find them.
Now I can can compile successfully and run my program, but it has the same 
issues.
But I notice the modified file win32kbd.inc is never used.   I have even 
removed it temporarily and I can still compile successfully.  I did a 
search for win32kbd and I find win32kbdd.inc but not win32kbd.inc

That is where I am at.  I think If I could correctly apply win32kbd.inc it may 
work

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 23, 2017 1:03 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 06:09 PM, James Richters wrote:
> I think I figured out my problem, but I'm not sure how to fix it.   I was 
> looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
> And I see that the change made was to win32kbd.inc, but I don't think I'm 
> using the updated version of it.   I think my problem is that I just compiled 
> ptcgraph.pp and replaced ptcgraph.ppu in FPCWin\units\i386-win32\graph so 
> apparently that's not the correct way to do it.So then I tried adding the 
> entire folder downloaded from https://sourceforge.net/projects/ptcpas/files/
But that's a fix, that's not yet released (because it needs testing), so it's 
in svn trunk only, and not in the release files. Get it from:

  https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Either click on "Download Snapshot", or install subversion (TortoiseSVN) and 
checkout https://svn.code.sf.net/p/ptcpas/code/trunk

> Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
> ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now 
> It can't find ptcgraph, even though it's there under  
> FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
> guessing and really don't have a clue the proper way to integrate this into 
> my fpc compiler.
>
> Could someone please tell me the correct way I should be doing this so that 
> the compiler will find the correct versions of all the files necessary?
>
> James
>
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of James Richters
> Sent: Monday, May 22, 2017 7:13 PM
> To: 'FPC-Pascal users discussions' 
> Subject: Re: [fpc-pascal] FPC Graphics options?
>
>> Here is a simple sample program that has the issue for me on both my windows 
>> 10 desktop and my windows 10 laptop, both are 64bit.
>> https://hastebin.com/nubonozaho.pas
> I started thinking about this, and did some more tests, and I think I have 
> narrowed down what is really happening, but not sure how to fix it.
>
> The problem is not the ALT-tab from the graphics window,  it's ALT being 
> pressed when the window focus changes.   CTRL is also affected, but not 
> shift.  Try this:
> Go to Graph window,  type some letters,  see that it's working correctly,  
> now hold just ALT, or CTRL - switch to another window by clicking on it.  
> Click on console window, see letters are working correctly, now go back to 
> graph window,  anything you press acts like ALT, or CTRL is still being 
> pressed until you actually enter a keystro

Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

[James Richters]

>all i get is a dark blue screen there... no text or anything that i can see to 
>download or copy...

That's strange.. it worked yesterday but not today, I tried to create it again 
with hastebin but it's not working.   here is a new link using pastebin instead
https://pastebin.com/3ARG0zQU

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
wkitt...@windstream.net
Sent: Tuesday, May 23, 2017 2:16 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

On 05/22/2017 05:38 PM, James Richters wrote:
>> I cannot reproduce it on my machine after the r714 fix. Can you send 
>> me a small example program, that demonstrates the problem, as well as 
>> detailed steps to reproduce? >
> Here is a simple sample program that has the issue for me on both my 
> windows
> 10 desktop and my windows 10 laptop, both are 64bit. > 
> https://hastebin.com/nubonozaho.pas

all i get is a dark blue screen there... no text or anything that i can see to 
download or copy...

--
  NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list unless*
*a signed and pre-paid contract is in effect with us.* 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

>Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
>units\i386-win32 from the snapshot directory to the unit search path of your 
>compiler.

When I try to follow the instructions, I get:
fpcmake -r
Processing Makefile.fpc
Error: Target "win32", package "rtl" not found

I have fpcdir=j:\Programming\fpc 3.0.2  set in my environment variables

Make -v  reports:
GNU Make 3.82
Built for i686-pc-mingw32

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 23, 2017 2:07 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/23/2017 08:28 PM, James Richters wrote:
> I have done the "download snapshot" but I just don't know what to do with it 
> now to properly integrate it into my compiler.
Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
units\i386-win32 from the snapshot directory to the unit search path of your 
compiler.
>
> Here is what I have tried to do.
> First I moved everything from J:\Programming\FPC 
> 3.0.2\units\i386-win32\graph to a temporary location so it wouldn't 
> find the old versions of ptcgraph and ptccrt Now when I try to compile 
> my program, I get unit ptcgraph not found... which is what I want because I 
> want to be sure not to get the old version Then I copied the entire snapshot 
> to into J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas Now when I try to 
> compile my program, I still get unit ptcgraph not found.
> I added J:\Programming\FPC 3.0.2\units\$fpctarget\ptcpas\* to the 
> directories Now I got an error that it could not find graphh.inc So I 
> copied all the .inc files from J:\Programming\FPC 
> 3.0.2\units\i386-win32\graph\inc to J:\Programming\FPC 
> 3.0.2\units\i386-win32\graph because I have no idea how else to make it find 
> them.
> Now I can can compile successfully and run my program, but it has the same 
> issues.
> But I notice the modified file win32kbd.inc is never used.   I have even 
> removed it temporarily and I can still compile successfully.  I did a 
> search for win32kbd and I find win32kbdd.inc but not win32kbd.inc
>
> That is where I am at.  I think If I could correctly apply 
> win32kbd.inc it may work
>
> James
>
>
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of Nikolay Nikolov
> Sent: Tuesday, May 23, 2017 1:03 PM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] FPC Graphics options?
>
>
>
> On 05/23/2017 06:09 PM, James Richters wrote:
>> I think I figured out my problem, but I'm not sure how to fix it.   I was 
>> looking at the code here: https://sourceforge.net/p/ptcpas/code/714/
>> And I see that the change made was to win32kbd.inc, but I don't think I'm 
>> using the updated version of it.   I think my problem is that I just 
>> compiled ptcgraph.pp and replaced ptcgraph.ppu in 
>> FPCWin\units\i386-win32\graph so apparently that's not the correct way 
>> to do it.So then I tried adding the entire folder downloaded from 
>> https://sourceforge.net/projects/ptcpas/files/
> But that's a fix, that's not yet released (because it needs testing), so it's 
> in svn trunk only, and not in the release files. Get it from:
>
>https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/
>
> Either click on "Download Snapshot", or install subversion 
> (TortoiseSVN) and checkout https://svn.code.sf.net/p/ptcpas/code/trunk
>
>> Into a folder at FPCWin\units\i386-win32\ptcpas  then renaming the original 
>> ptccrt.ppu and ptcgraph.ppu located in FPCWin\units\i386-win32\graph but now 
>> It can't find ptcgraph, even though it's there under  
>> FPCWin\units\i386-win32\ptcpas\ptcgraph so now I'm realizing that I'm just 
>> guessing and really don't have a clue the proper way to integrate this into 
>> my fpc compiler.
>>
>> Could someone please tell me the correct way I should be doing this so that 
>> the compiler will find the correct versions of all the files necessary?
>>
>> James
>>
>>
>> -Original Message-
>> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
>> Behalf Of James Richters
>> Sent: Monday, May 22, 2017 7:13 PM
>> To: 'FPC-Pascal users discussions' 
>> Subject: Re: [fpc-pascal] FPC Graphics options?
>>
>>> Here is a simple sample program that has the issue for me on both my 
>>> windows 10 desktop and my windows 10 laptop, both are 64bit.
>>> https://hastebi

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

>Just like you now use -FuSomePath to tell the compiler where to find units, 
>you can use -FiSomePath to tell the compiler where to look for include files.

I've been trying to compile with Free Pascal Text IDE, I have no experience 
with compiling programs from the command line,  but this gave me an idea to try 
it from command line instead.

First, I thought I would start clean, and  I re-installed Free Pascal and left 
the directory structure alone, and just changed the drive to H: where I have a 
lot of room. I suspect it did not like the space I had in my directory name.
From the new install of FPC 3.0.2 on my H Drive, I was able to successfully 
follow the instructions and I finally managed to compile ptcpas-code-715-trunk.

I was also able to compile the examples and they executed correctly.  So I used 
the command line used to compile one of the examples, and put the whole path of 
ptcpas in and I was finally able to successfully compile my test program with 
the following command line:
h:/FPC/3.0.2/bin/i386-Win32/ppc386.exe 
-Fuh:/ptcpas-code-715-trunk/units/i386-win32/ -FE. 
-FUh:/ptcpas-code-715-trunk/units/i386-win32 -di386 dual-key-screen.pas
When I compiled It this way, I am now able to ALT-Tab from the graph window and 
when I return everything is fine,  so this proves the problem has been solved, 
but integrating the solution into my compiler is the problem.

I am trying to get it to work from the Free Pascal text mode IDE
but when I add h:\ptcpas-code-715-trunk\units\i386-win32 to the list of unit 
directories in the Free Pascal text IDE and try to compile my program, I get:

PPU Loading H:\ptcpas-code-715-trunk\units\i386-win32\ptcgraph.ppu 
║ PPU Source: ptcgraph.pp not found
║ PPU Source: graphh.inc not available
║ PPU Source: graph.inc not available
║ PPU Source: fontdata.inc not available
║ PPU Source: clip.inc not available
║ PPU Source: palette.inc not available
║ PPU Source: modes.inc not available
║ PPU Source: fills.inc not available
║ PPU Source: gtext.inc not available
║ Recompiling ptcgraph, checksum changed for ptc
║ dual-key-screen.pas(3,6) Fatal: Can't find unit ptcgraph used by KeyTestWin.p
║ dual-key-screen.pas(0) Fatal: Compilation aborted

How do I properly use the FreePascal Text mode IDE to use the ptcpas units I 
compiled?

My entries under directories > Units are:
H:\ptcpas-code-715-trunk\units\i386-win32
h:\FPC\3.0.2\units\$fpctarget
h:\FPC\3.0.2\units\$fpctarget\*
h:\FPC\3.0.2\units\$fpctarget\rtl

All other directories tabs are blank

Thanks for the help

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Ewald
Sent: Tuesday, May 23, 2017 2:03 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

On 23/05/17 19:50, James Richters wrote:
> *correction  to directory names:
> Now I got an error that it could not find graphh.inc So I copied all the .inc 
> files from J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph\inc  to 
> J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph because I have no 
> idea how else to make it find them.

Just like you now use -FuSomePath to tell the compiler where to find units, you 
can use -FiSomePath to tell the compiler where to look for include files.

See `fpc -h`, under the section "-F Set file names and paths:" for a list of 
other related switches.


--
Ewald
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I was finally able to get this working, and now my keyboard issues are solved, 
so thank for the help and fix Nikolay!  I can't believe the performance 
increase using ptcgraph instead of graph, I am now even able to run my program 
on a tiny windows 10 tablet with no performance issues.  Also ptccrt solves 
some of the bugs with wincrt, mainiy that wincrt doesn't respond to any alt 
keys at all and not all of the crtl keys

What I finally realized was there was another set of PTC units with the default 
installation of Freepascal 3.0.2 that I needed to remove so the correct 
versions of the files could be found. 

Perhaps it would be a good idea to make note of this in the instructions?  

I ended up needing to remove:
H:\FPC\3.0.2\units\i386-win32\graph\ptcgraph.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptcgraph.0 
H:\FPC\3.0.2\units\i386-win32\graph\ptccrt.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptccrt.0 
H:\FPC\3.0.2\units\i386-win32\graph\ptcmouse.ppu
H:\FPC\3.0.2\units\i386-win32\graph\ptcmouse.0

And the entire folder  H:\FPC\3.0.2\units\i386-win32\ptc

Also I could not compile with a space in my FPC install directory, so a quick 
comment about that may be useful to someone.


James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Tuesday, May 23, 2017 5:40 PM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] FPC Graphics options?

>Just like you now use -FuSomePath to tell the compiler where to find units, 
>you can use -FiSomePath to tell the compiler where to look for include files.

I've been trying to compile with Free Pascal Text IDE, I have no experience 
with compiling programs from the command line,  but this gave me an idea to try 
it from command line instead.

First, I thought I would start clean, and  I re-installed Free Pascal and left 
the directory structure alone, and just changed the drive to H: where I have a 
lot of room. I suspect it did not like the space I had in my directory name.
From the new install of FPC 3.0.2 on my H Drive, I was able to successfully 
follow the instructions and I finally managed to compile ptcpas-code-715-trunk.

I was also able to compile the examples and they executed correctly.  So I used 
the command line used to compile one of the examples, and put the whole path of 
ptcpas in and I was finally able to successfully compile my test program with 
the following command line:
h:/FPC/3.0.2/bin/i386-Win32/ppc386.exe 
-Fuh:/ptcpas-code-715-trunk/units/i386-win32/ -FE. 
-FUh:/ptcpas-code-715-trunk/units/i386-win32 -di386 dual-key-screen.pas When I 
compiled It this way, I am now able to ALT-Tab from the graph window and when I 
return everything is fine,  so this proves the problem has been solved, but 
integrating the solution into my compiler is the problem.

I am trying to get it to work from the Free Pascal text mode IDE but when I add 
h:\ptcpas-code-715-trunk\units\i386-win32 to the list of unit directories in 
the Free Pascal text IDE and try to compile my program, I get:

PPU Loading H:\ptcpas-code-715-trunk\units\i386-win32\ptcgraph.ppu
║ PPU Source: ptcgraph.pp not found
║ PPU Source: graphh.inc not available
║ PPU Source: graph.inc not available
║ PPU Source: fontdata.inc not available ║ PPU Source: clip.inc not available ║ 
PPU Source: palette.inc not available ║ PPU Source: modes.inc not available ║ 
PPU Source: fills.inc not available ║ PPU Source: gtext.inc not available ║ 
Recompiling ptcgraph, checksum changed for ptc ║ dual-key-screen.pas(3,6) 
Fatal: Can't find unit ptcgraph used by KeyTestWin.p ║ dual-key-screen.pas(0) 
Fatal: Compilation aborted

How do I properly use the FreePascal Text mode IDE to use the ptcpas units I 
compiled?

My entries under directories > Units are:
H:\ptcpas-code-715-trunk\units\i386-win32
h:\FPC\3.0.2\units\$fpctarget
h:\FPC\3.0.2\units\$fpctarget\*
h:\FPC\3.0.2\units\$fpctarget\rtl

All other directories tabs are blank

Thanks for the help

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Ewald
Sent: Tuesday, May 23, 2017 2:03 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] [FPC-Pascal] FPC Graphics options?

On 23/05/17 19:50, James Richters wrote:
> *correction  to directory names:
> Now I got an error that it could not find graphh.inc So I copied all the .inc 
> files from J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph\inc  to 
> J:\Programming\FPC 3.0.2\units\i386-win32\ptcpas\ptcgraph because I have no 
> idea how else to make it find them.

Just like you now use -FuSomePath to tell the compiler where to find units, you 
can use -FiSomePath to tell the compiler where to look for include files.

See `fpc -h`, under the section "-F Set file names and paths:" for a list of 
other related switches.


--
Ewald
_

Re: [fpc-pascal] ptccrt missing keys

[James Richters]

>It's great that it's finally working for you. And yes, ptccrt supports most 
>alt and ctrl key combinations, but if you find some key combination missing, 
>please report it - it is easy to add.

I could really use F11 and F12  including shift, alt, and crtl if possible from 
the prccrt graphics window.  I suspect there is some fundamental reason why F11 
and F12 aren't usable, because F11 and F12 don't work in crt either.  But here 
is what does work in crt that would be great if would also work in ptccrt.

  F11 - no code but toggles the console window full screen and back-  
If F11 could not be caputed I would rather it NOT try to change full screen on 
the ptcgraph window
  F12 - Extended: #134
Shift F11 - Extended: #135
Shift F12 - Extended: #136
CTRL F11 - Extended: #137
CTRL F12 - Extended: #138
  ALT F11 - Extended: #139
Alt F12 - Extended: #140

Interestingly ATL-F4 does not close the ptcgraph window, it returns extended 
#107 followed by #3I also notice that hitting the X on ptcgraph window 
sends a #3 which I like MUCH better than just closing the window.  I am going 
to use these to initiate my exit sequence and properly exit the program instead 
of terminating it.  It would be great to not get the #3 after the #107 for 
ALT-F4 just to make it completely different than hitting the X, but it's 
workable to trap #107 then ignore the #3 if I want Alt-F4 to be different than 
X or ignore #107 if I want Alt-F4 to be the same as X, so maybe best to leave 
it the way it is.

Here are some keys that work in CRT and their codes, I personally don't have an 
immediate use for them but it they were available I might think of something
 CTRL Insert - Extended: #146
CTRL Delete - Extended: #147
   ALT Delete - Extended: #163
ALT Home - #7
   ALT END - #1
   ALT =  - Extended #131
   ALT ~  - Extended #41
  CTRL ~ - Extended #41 * CTRL + and ALT + are the same, would be nice if 
they were not.
The following are from the numbers above letters on keyboard
 CTRL 1 - Extended #2
 Yes CTRL 2 already works and produces Extended #3
  CTRL 3 - Extended #4
  CTRL 4 - Extended #5
  CTRL 5 - Extended #6
  CTRL 6 - Extended #7   -  ptcgraph produces Extended #30 instead
  CTRL 7 - Extended #8
  CTRL 8 - Extended #9
  CTRL 9 - Extended #10
  CTRL 0 - Extended #11
  CTRL -   - Extended #12  -  ptcgraph produces Extended #31 instead
  CTRL =  - Extended #13

The following are from numeric keypad
  CTRL 1 - Extended #117
  CTRL 2 - Extended #145
  CTRL 3 - Extended #118
  CTRL 4 - Extended #115
  CTRL 5 - Extended #143
  CTRL 6 - Extended #116
  CTRL 7 - Extended #119
  CTRL 8 - Extended #141
  CTRL 9 - Extended #132
  CTRL 0 - Extended #146
   CTRL .  - Extended #147 

I'm not sure about these, it seems kind of like more of a test than real 
keycodes, but this is what CRT does
   ALT 1 - #1
   ALT 2 - #2
   ALT 3 - #3
   ALT 4 - #4
   ALT 5 - #5
   ALT 6 - #6
   ALT 7 - #7
   ALT 8 - #8 * Backspace
   ALT 9 - #9 * Tab
   ALT .  - Extended #163

The following are the operators from the numeric keypad
   CTRL / - Extended: #149  
   ALT / - Extended: #164  
   CTRL * - Extended: #150  
  ALT * - Extended: #55
CTRL -  - Extended: #142  
  ALT -  - Extended: #74
CTRL +  - Extended: #78
   ALT +  - Extended: #78 *CTRL + and ALT + are the same, would be nice 
if they were not.


James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ptccrt missing keys

[James Richters]

Having some kind of Keyboard Mode selection Variable that defaults to TP 
compatibility would be a great option.

James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Sunday, May 28, 2017 9:52 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] ptccrt missing keys



On 05/26/2017 10:49 PM, James Richters wrote:
>> It's great that it's finally working for you. And yes, ptccrt supports most 
>> alt and ctrl key combinations, but if you find some key combination missing, 
>> please report it - it is easy to add.
> I could really use F11 and F12  including shift, alt, and crtl if possible 
> from the prccrt graphics window.  I suspect there is some fundamental reason 
> why F11 and F12 aren't usable, because F11 and F12 don't work in crt either.  
> But here is what does work in crt that would be great if would also work in 
> ptccrt.
>  
> lots of missing keys
Unfortunately, all of the missing keys and differences from ptccrt (including 
the very odd ones) stem from the fact that ptccrt behaves _exactly_ like the 
crt unit in Turbo Pascal 7 under DOS, with a 100% IBM compatible keyboard and 
BIOS. This includes the lack of support for extended keys (like F11 and F12). 
The Windows crt unit doesn't conform strictly to that, however, so that's why 
there are differences. I don't want to sacrifice the DOS/TP7 crt unit 
compatibility, so I'll have to think of something, but it'll take a little 
time. Perhaps I'll add different keyboard compatibility "modes" or something 
like that.

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>As I mentioned, AggPas can use allocated memory, array, a memory image etc as 
>its rendering buffer. If you want a graphical console program
>(eg: using Linux Console Framebuffer) using AggPas, then render your 
>application output via AggPas to a memory image, then bitblit that image
>to the console graphics output in whatever paint event you have available.

>Using AggPas with desktop GUI applications works pretty much identical as 
>above, except it bitblit's the memory image to the Window Canvas.

What is the best method for getting the memory image to a ptcgraph window?  I 
have been trying to figure how to use something like putimage to do this but 
I'm not sure how to do it or if it's even the best way.I think I probably 
need to convert the format of the memory buffer or something, but I can't 
figure out what to do.

I've re-attached Graeme's sample slightly modified to open the ptcgraph window, 
and attempt to use putimage on line 103 but when I run it I get 217- access 
violation

Any advice on how to get the image into the window is greatly appreciated.

James


Agg2DConsole.dpr
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>  * What parameters does its putimage() function take?
>  * Does in support PNG image format natively?

Putimage() takes
Initial X position
Initial Y position
Pointer to beginning of memory bitmap
Method to use (copy, AND, OR, XOR)  
See https://www.freepascal.org/docs-html/rtl/graph/putimage.html


Here's an example:
Var Q: Pointer;
   Bar(0, 0, (GetMaxX div 3), GetMaxY);
   Size := ImageSize(10, 20, 30, 40);
   GetMem(Q, Size);   { Allocate memory on heap }
   GetImage(10, 20, 30, 40, Q^);
   Readln;
   ClearDevice;
   PutImage(100, 100, Q^, NormalPut);
   readln;
   putimage(0,0,Q^,normalput);
   readln;

I can get this to work with getimage and putimage, but I have no idea how to 
build the image in memory and just use putimage.

I don't think it really supports any 'image formats'  it's just the TP 
compatible graphics thing for DOS style graphics.

I'm looking at it and I think getimage / putimage are just one byte per 
pixel... maybe?  so probably not what I want. 
I'm getting the feeling this is apples and oranges here, TP compatible memory 
map vs tcolor or tfpcolor or some other scheme with 4 bytes per pixel.
Maybe there just isn't anything canned that can do what I want?  Maybe I need 
to put the pixels on the screen myself using a nested loop and getpixel / 
putpixel and do whatever logic on my own.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Tuesday, May 30, 2017 4:55 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-05-30 20:20, James Richters wrote:
> I've re-attached Graeme's sample slightly modified to open the 
> ptcgraph window, and attempt to use putimage on line 103 but when I 
> run it I get 217- access violation

I haven't downloaded or looked at ptcgraph at all. A few questions:

  * What parameters does its putimage() function take?
  * Does in support PNG image format natively?

I would imagine that it probably supports BMP only - comping from DOS and 
Windows background. If so, change the example program to use a BMP image 
instead of a PNG image. In your code you attached you are actually pushing the 
c variable, which is a TFPColor record of the last color retrieve from the 
AggPas buffer - so no surprise you are getting a AV error.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

I was doing some tests with Putpixel and that seems to be a word in the format 
of RGBA with 4 bits each.I would think putimage would use the same format, 
but I haven't tested that yet.

I'm still a bit confused by putimage, since it only has an X and Y startpoint, 
how do you define the height and width of the bitmap? Getimage() specifies a 
rectangle, and imagesize() figures out how much memory you need, but I just 
don't what defines the size and shape of the image to putimage.

I managed to get the test out of the buffer and onto the screen with :

  function getBufItemAsByte(aDelta: Word): Byte;
  var
actualY: Integer;
thing:Byte;
  begin
actualY := ImageHeight - y - 1;
thing :=
  byte(buf[x * RGBA_Width + actualY * ImageWidth * RGBA_Width + aDelta]);
result:=thing shr 4;  //colors channels are reduced to 4 bits each, they 
are not correct
  end;

for x := 0 to ImageWidth - 1 do
   for y := 0 to ImageHeight - 1 do
   begin
  pixelcolor:=(getBufItemAsbyte(2) shl 12)+(getBufItemAsbyte(1) shl 8) 
+(getBufItemAsbyte(0) shl 4)+getBufItemAsbyte(3);
  putpixel(x,y,pixelcolor);
  end;


James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Tuesday, May 30, 2017 8:19 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-05-30 22:37, James Richters wrote:

> Putimage() takes
> Initial X position
> Initial Y position
> Pointer to beginning of memory bitmap

In that case the AggPas code should be even faster, because PutImage() only 
want a pointer to the bitmap data - thus no need to go through the slow FPImage 
code to generate a PNG or BMP image. The pixel-by-pixel conversions for FPImage 
is very slow.

>Size := ImageSize(10, 20, 30, 40);
>GetMem(Q, Size);   { Allocate memory on heap }

So you can do pretty much the same with AggPas then. Allocate the memory you 
need, and attach that as the rendering buffer or AggPas. As I mentioned before, 
AggPas just needs to know what memory it can write too, and in what format you 
want that rendered data to be. AggPas supports many render buffer formats. BGR, 
BGRA, RGB, RGBA, Gray8, rgb555, rgb565 etc etc. And if an existing render 
buffer format doesn't exist, it is really easy and quick to add a new one - 
just a few really simple procedures to implement.

See the pf_*.inc files for plenty of examples. The "pf_" prefix stands for 
"pixel format definition".


> I'm looking at it and I think getimage / putimage are just one byte per 
> pixel... maybe?

I'll see if I can get graph or ptcgraph working working here under 
FreeBSD, then I'll take a look at what pixel format they use.


Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>seems to be a word in the format of RGBA with 4 bits each

Well, it seemed to be RGBA, but it's not...  

It's a word with:
5bits red, 6bits green, and 5bits blue like this:

RGGB

I'm not sure what that's called or how to set up aggpas to use that, but that's 
what it seems to be if ptcgraph is put in a 16bit color mode.  It doesn't seem 
to be able to go any higher than that, but that's fine for my purposes.

James




-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Wednesday, May 31, 2017 7:52 AM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

I was doing some tests with Putpixel and that seems to be a word in the format 
of RGBA with 4 bits each.I would think putimage would use the same format, 
but I haven't tested that yet.

I'm still a bit confused by putimage, since it only has an X and Y startpoint, 
how do you define the height and width of the bitmap? Getimage() specifies a 
rectangle, and imagesize() figures out how much memory you need, but I just 
don't what defines the size and shape of the image to putimage.

I managed to get the test out of the buffer and onto the screen with :

  function getBufItemAsByte(aDelta: Word): Byte;
  var
actualY: Integer;
thing:Byte;
  begin
actualY := ImageHeight - y - 1;
thing :=
  byte(buf[x * RGBA_Width + actualY * ImageWidth * RGBA_Width + aDelta]);
result:=thing shr 4;  //colors channels are reduced to 4 bits each, they 
are not correct
  end;

for x := 0 to ImageWidth - 1 do
   for y := 0 to ImageHeight - 1 do
   begin
  pixelcolor:=(getBufItemAsbyte(2) shl 12)+(getBufItemAsbyte(1) shl 8) 
+(getBufItemAsbyte(0) shl 4)+getBufItemAsbyte(3);
  putpixel(x,y,pixelcolor);
  end;


James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Tuesday, May 30, 2017 8:19 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-05-30 22:37, James Richters wrote:

> Putimage() takes
> Initial X position
> Initial Y position
> Pointer to beginning of memory bitmap

In that case the AggPas code should be even faster, because PutImage() only 
want a pointer to the bitmap data - thus no need to go through the slow FPImage 
code to generate a PNG or BMP image. The pixel-by-pixel conversions for FPImage 
is very slow.

>Size := ImageSize(10, 20, 30, 40);
>GetMem(Q, Size);   { Allocate memory on heap }

So you can do pretty much the same with AggPas then. Allocate the memory you 
need, and attach that as the rendering buffer or AggPas. As I mentioned before, 
AggPas just needs to know what memory it can write too, and in what format you 
want that rendered data to be. AggPas supports many render buffer formats. BGR, 
BGRA, RGB, RGBA, Gray8, rgb555, rgb565 etc etc. And if an existing render 
buffer format doesn't exist, it is really easy and quick to add a new one - 
just a few really simple procedures to implement.

See the pf_*.inc files for plenty of examples. The "pf_" prefix stands for 
"pixel format definition".


> I'm looking at it and I think getimage / putimage are just one byte per 
> pixel... maybe?

I'll see if I can get graph or ptcgraph working working here under FreeBSD, 
then I'll take a look at what pixel format they use.


Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>And AggPas already has support for that pixel format

How do I define that as the format I want?  I've been looking all through the 
example and do not see how this is defined.  I've attached a test program, it's 
basically Graeme's sample but going to screen instead of a file.  I just don't 
see where the pixel format is defined.  I have it kind of working in a funny 
way by just forcing the existing pixels to conform to the required format. 

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Wednesday, May 31, 2017 1:17 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-05-31 18:03, Reimar Grabowski wrote:
>> I'm not sure what that's called
> RGB565, maybe?

And AggPas already has support for that pixel format.

Regards,
   Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Graphtest2.pas
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

Thanks for the help. I was able to make a little progress.

>There is another agg unit agg_pixfmt_rgb_packed that seem to have the
>565 format that you need. Add it to the uses list and try to replace the
>pixfmt_rgba32 calls with pixfmt_rgb565. That will make agg use that format.
>The pixfmt_custom_blend_rgba calls may need further hacking too to make things 
>work, however, Agg2D should use a 16 bit format if you use
>pixfmt_rgb565 callse instead of pixfmt_rgba32. You should also set RGBA_Width 
>=2; in your program to reflect the change.

I did as you suggest here and changed my buffer to be an array of words, and I 
am able to get a representation of the image to screen by reading elements of 
the array and using putpixel() to put them on the screen,  however the colors 
are all wrong.  I am wondering if this m_pixformat variable that shows up 
everywhere needs to be set also?   The pixfmt_custom_blend_rgba calls may also 
be the problem with the colors.  There are no corresponding custom blend 
procedures in agg_pixfmt_rgb_packed.

>Anyway, this will probably still not make
>ptcgraph.putimage(0,0,buf[0],0);
No this still does not work, I am able to use a nested loop and putpixel() but 
that is very slow.  I still think something is missing with putimage because I 
don't see how it knows the shape of the image, maybe I need to actually do a 
getimage() at some point to set the shape of before putimage will work.. I'll 
do some experiments with it.  

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Stefan V. Pantazi
Sent: Thursday, June 01, 2017 9:47 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

Have a look at the agg_2D unit. The agg_2D uses ..
  agg_pixfmt ,
  agg_pixfmt_rgba ,
..

Therefore, the rgba format is pretty much baked in. That is to say that the 
constructor of the main object Agg2D uses the pixfmt_rgba32 to set the pixel 
format.

...
{ CONSTRUCT }
constructor Agg2D.Construct;
begin
  m_rbuf.Construct;

  pixfmt_rgba32   (m_pixFormat ,@m_rbuf );
  pixfmt_custom_blend_rgba(m_pixFormatComp ,@m_rbuf ,@comp_op_adaptor_rgba 
,rgba_order );
  pixfmt_rgba32   (m_pixFormatPre ,@m_rbuf );
  pixfmt_custom_blend_rgba(m_pixFormatCompPre ,@m_rbuf ,@comp_op_adaptor_rgba 
,rgba_order ); ...

There is another agg unit agg_pixfmt_rgb_packed that seem to have the
565 format that you need. Add it to the uses list and try to replace the
pixfmt_rgba32 calls with pixfmt_rgb565. That will make agg use that format.

The pixfmt_custom_blend_rgba calls may need further hacking too to make things 
work, however, Agg2D should use a 16 bit format if you use
pixfmt_rgb565 callse instead of pixfmt_rgba32. You should also set RGBA_Width 
=2; in your program to reflect the change.

Anyway, this will probably still not make

ptcgraph.putimage(0,0,buf[0],0);
work, but that may be a ptcgraph problem.


Hope this helps,

Stefan

On 05/31/2017 02:57 PM, James Richters wrote:
>> And AggPas already has support for that pixel format
>
> How do I define that as the format I want?  I've been looking all through the 
> example and do not see how this is defined.  I've attached a test program, 
> it's basically Graeme's sample but going to screen instead of a file.  I just 
> don't see where the pixel format is defined.  I have it kind of working in a 
> funny way by just forcing the existing pixels to conform to the required 
> format.
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of Graeme Geldenhuys
> Sent: Wednesday, May 31, 2017 1:17 PM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
>
> On 2017-05-31 18:03, Reimar Grabowski wrote:
>>> I'm not sure what that's called
>> RGB565, maybe?
>
> And AggPas already has support for that pixel format.
>
> Regards,
>Graeme
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

Thanks for figuring out how to make this work, I would have never figured it
out with the documentation I was able to find.

I'm out of town this week so I tried to download the sample program to my
laptop and discovered another issue.  While I can normally just compile my
programs on my laptop and run them,  I have noticed that I can't do this
with programs with aggpas in them. They compile successfully but when I try
to run them I get a "system error: The Program can't start because
MSVCR71.dll is missing from your computer.  Try reinstalling the program to
fix this problem"  I suspect I get this because I have never actually
installed free Pascal or something that I happened to install on my
development pc on my laptop, I have always run freepascal it from a backup
made from my development machine.   I have not tried installing freepascal
on my lap top yet because I would like to figure out what I will need to do
on my target installations where freepascal will not be installed.  

Any ideas on what causes this error and advice on how to install what is
needed on client (non-development) systems?

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf
Of Stefan V. Pantazi
Sent: Saturday, June 03, 2017 12:45 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

I seem to have some problems with logging on the bug tracker. I've used it
in the recent past a couple of time but I am unable to log on for some
reason. I will try later to create a new account and submit a fpc doc bug
report.

At any rate, I attached the updated example based on Nikolay's recent post
which had the correct information. There was a third "reserved" 
parameter that had to be added to the bitmap buffer structure. Without it,
the output was slightly clipped to the right. Also, for the example to work,
the agg object constructor must be modified as well, I included all the info
in the example header. I think the example program
(aggpas_ptcgraph_output.pas) fits well together with the other demos in
fpGUI and PtcPas/ptcgraph packages, so adding it to the packages would help,
regardless whether graph.PutImage documentation is updated.

Stefan

On 06/03/2017 06:52 AM, Graeme Geldenhuys wrote:
> On 2017-06-03 01:56, Stefan V. Pantazi wrote:
>> http://pascal.net.ru/PutImage+(en)
>> [...]
>> "BitMap is an untyped parameter that contains the height and width of
>> the region, and the bit image that will be put onto the screen."
>> [...]
>
>
> Could you file a FPC Documentation bug report and ask that this
> information be added. As you found out (very difficultly), this is vital
> information.
>
>
> Regards,
>   Graeme
>

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>As for font support under Windows. Yes you can use GDI for font rendering, but 
>I highly recommend using freetype.dll even under Windows. 
>It has more features than GDI font support and the quality is better too.

Is it the fonts causing the dependency then?  I have freetype.dll included in 
the directory with my programs, do I need to include other files / dlls if I 
want them to run without installing anything?

the programs I am getting the dependency  issue with are based on and including 
Graeme's original sample program Agg2DColsole.dpr ,  they use:
Ptcgraph,
Ptccrt,
Sysutils,
Fpimage,
Fpwritepng,
Agg_2d,
Agg_Basics


James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, June 05, 2017 2:25 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-06-05 03:12, Stefan V. Pantazi wrote:
> In my experience, the one dependency that AggPas has potential to fail 
> may be related to the freetype library. If you plan to run your app on 
> windows only, then you can turn freetype off and AggPas will happily 
> use windows font libraries. Search for the AGG2D_USE_FREETYPE define 
> and comment it out.

Correct, though even font support is optional in AggPas. So if you don't render 
text via AggPas, it has zero dependency - everything is done in pure Object 
Pascal code.

As for font support under Windows. Yes you can use GDI for font rendering, but 
I highly recommend using freetype.dll even under Windows. 
It has more features than GDI font support and the quality is better too.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>How did you build/get freetype.dll?

I don't know how it was built, I swiped it from the AggPas24-rm3.zip file and 
it seemed to work.
I did find msvcr71.dll by searching my entire development pc hard drive and 
found it in C:\Program Files (x86)\StarWind Software\StarWind V2V Image 
Converter\lib\ and  Transferred it to my laptop and put it in the same 
directory as my test program and now it's running fine.  

>You may benefit from such tool as a dependency walker 
>(https://en.wikipedia.org/wiki/Dependency_Walker).

Thanks for the advice, I will check it out.

Jim


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Stefan V. Pantazi
Sent: Monday, June 05, 2017 6:19 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

How did you build/get freetype.dll? If it was built using Visual Studio, 
freetype.dll might have been linked against a newer C++ runtime such as 
msvcr71.dll that is not shipped with windows by default. You clearly need to 
deploy C++ runtime libs as well with your product.
You may benefit from such tool as a dependency walker 
(https://en.wikipedia.org/wiki/Dependency_Walker).
On linux you can just use ldd.

Hope this helps,

Stefan

On 06/05/2017 05:00 PM, James Richters wrote:
>> As for font support under Windows. Yes you can use GDI for font rendering, 
>> but I highly recommend using freetype.dll even under Windows.
>> It has more features than GDI font support and the quality is better too.
>
> Is it the fonts causing the dependency then?  I have freetype.dll included in 
> the directory with my programs, do I need to include other files / dlls if I 
> want them to run without installing anything?
>
> the programs I am getting the dependency  issue with are based on and 
> including Graeme's original sample program Agg2DColsole.dpr ,  they use:
> Ptcgraph,
> Ptccrt,
> Sysutils,
> Fpimage,
> Fpwritepng,
> Agg_2d,
> Agg_Basics
>
>
> James
>
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of Graeme Geldenhuys
> Sent: Monday, June 05, 2017 2:25 PM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
>
> On 2017-06-05 03:12, Stefan V. Pantazi wrote:
>> In my experience, the one dependency that AggPas has potential to 
>> fail may be related to the freetype library. If you plan to run your 
>> app on windows only, then you can turn freetype off and AggPas will 
>> happily use windows font libraries. Search for the AGG2D_USE_FREETYPE 
>> define and comment it out.
>
> Correct, though even font support is optional in AggPas. So if you don't 
> render text via AggPas, it has zero dependency - everything is done in pure 
> Object Pascal code.
>
> As for font support under Windows. Yes you can use GDI for font rendering, 
> but I highly recommend using freetype.dll even under Windows.
> It has more features than GDI font support and the quality is better too.
>
> Regards,
>Graeme
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
> http://fpgui.sourceforge.net/
>
> My public PGP key:  http://tinyurl.com/graeme-pgp 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
___
Stefan V. Pantazi, MD, PhD
Professor, Health Informatics
School of Health & Life Sciences and Community Services Conestoga College 
Institute of Technology and Advanced Learning
299 Doon Valley Drive
Kitchener, ON, Canada, N2G 4M4  
office: 1C23
phone:  (519) 748-5220 ext. 3950
email:  svpant...@gmail.com
web:https://sites.google.com/site/stefanvpantazi/   
___
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ptccrt missing keys

[James Richters]

>Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
>units\i386-win32 from the snapshot directory to the unit search path of your 
>compiler.

Can I have instructions on how to compile ptcpas for x86_64-win64?   

I tried guessing that I might need fpcmake -r -Tx86_64-win64

when I try that  I get :
Processing Makefile.fpc
 x86_64-win64 requires: rtl
 Writing Makefile
Processing demos/Makefile.fpc
 x86_64-win64 requires: rtl
 Writing Makefile
Processing examples/Makefile.fpc
 x86_64-win64 requires: rtl
 Writing Makefile
Processing test/Makefile.fpc
 x86_64-win64 requires: rtl
 Writing Makefile

But when I try to run make I get:

Makefile:208: *** The Makefile doesn't support target i386-win32, please run 
fpcmake first.  Stop.   

I tried looking at command line options for make but I don't see how to change 
the target to x86_64-win64, and anyway I might be doing it completely wrong so 
I think it's best to just ask

I also notice that the changes in https://sourceforge.net/p/ptcpas/code/742 
list  'dead key support under Windows and X11 (via XIM)' in the comments.
are the missing keys now working and if so do I need to enable them somehow?
 I haven't tried compiling this yet, I'm still using r715. I thought I 
would ask if it was ready first.

Thanks,

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Sunday, May 28, 2017 9:52 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] ptccrt missing keys



On 05/26/2017 10:49 PM, James Richters wrote:
>> It's great that it's finally working for you. And yes, ptccrt supports most 
>> alt and ctrl key combinations, but if you find some key combination missing, 
>> please report it - it is easy to add.
> I could really use F11 and F12  including shift, alt, and crtl if possible 
> from the prccrt graphics window.  I suspect there is some fundamental reason 
> why F11 and F12 aren't usable, because F11 and F12 don't work in crt either.  
> But here is what does work in crt that would be great if would also work in 
> ptccrt.
>  
> lots of missing keys
Unfortunately, all of the missing keys and differences from ptccrt (including 
the very odd ones) stem from the fact that ptccrt behaves _exactly_ like the 
crt unit in Turbo Pascal 7 under DOS, with a 100% IBM compatible keyboard and 
BIOS. This includes the lack of support for extended keys (like F11 and F12). 
The Windows crt unit doesn't conform strictly to that, however, so that's why 
there are differences. I don't want to sacrifice the DOS/TP7 crt unit 
compatibility, so I'll have to think of something, but it'll take a little 
time. Perhaps I'll add different keyboard compatibility "modes" or something 
like that.

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ptccrt missing keys

[James Richters]

>maybe try:

>make CPU_TARGET=x86_64 OS_TARGET=win64

Here is what I have now:

H:\ptcpas-code-715-trunk>make CPU_TARGET=x86_64 OS_TARGET=win64 
J:/Programming/FPC/3.0.2/bin/i386-Win32/ppcrossx64.exe -Twin64 -Px86_64 
-XPx86_64-win64- -Xr -Fuhermes -Fuptcwrapper -Fuptcgraph -Fux11 
-Fuwin32/directx -Fiptcgraph/inc -FE. -FUunits/x86_64-win64 -dx86_64 ptc.pp
Warning: Option "-Xr" is ignored for the current target platform.
Free Pascal Compiler version 3.0.2 [2017/02/13] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling ptc.pp
ptc.pp(125,21) Fatal: Can't find unit glext used by ptc
Fatal: Compilation aborted
make: *** [ptc.ppu] Error 1

It seems like it can't find my units but it specifies -FUunits/x86_64-win64   
maybe I need to give it the full path to my units for 64bit?

> please be patient, it'll get there, maybe in a few week's time
I will be happy to be patient 😊  Thank you for all your hard work on this!

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Monday, June 12, 2017 6:56 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] ptccrt missing keys



On 06/13/2017 01:33 AM, James Richters wrote:
>> Follow the instructions in docs/INSTALL.txt to compile the package. Then add 
>> units\i386-win32 from the snapshot directory to the unit search path of your 
>> compiler.
> Can I have instructions on how to compile ptcpas for x86_64-win64?
>
> I tried guessing that I might need fpcmake -r -Tx86_64-win64
>
> when I try that  I get :
> Processing Makefile.fpc
>   x86_64-win64 requires: rtl
>   Writing Makefile
> Processing demos/Makefile.fpc
>   x86_64-win64 requires: rtl
>   Writing Makefile
> Processing examples/Makefile.fpc
>   x86_64-win64 requires: rtl
>   Writing Makefile
> Processing test/Makefile.fpc
>   x86_64-win64 requires: rtl
>   Writing Makefile
>
> But when I try to run make I get:
>
> Makefile:208: *** The Makefile doesn't support target i386-win32, please run 
> fpcmake first.  Stop.
maybe try:

make CPU_TARGET=x86_64 OS_TARGET=win64
>
> I tried looking at command line options for make but I don't see how 
> to change the target to x86_64-win64, and anyway I might be doing it 
> completely wrong so I think it's best to just ask
>
> I also notice that the changes in https://sourceforge.net/p/ptcpas/code/742 
> list  'dead key support under Windows and X11 (via XIM)' in the comments.
> are the missing keys now working and if so do I need to enable them somehow?  
>I haven't tried compiling this yet, I'm still using r715. I thought I 
> would ask if it was ready first.
Not yet. I'm still working on it. I ended up revamping all the keyboard input 
support in ptcpas, because I discovered there are some differences between 
linux and windows in the keycodes for some keys. Since, these are OEM-specific 
keys, so they differ between keyboard layouts, I tried different keyboard 
layouts and I discovered that dead keys don't work. 
So, I started digging in order to find out why that's the case. So, after a lot 
of changes, I got them working under both windows and linux. 
After that, I figured out it's time to prepare a new ptcpas release, because 
there are many other changes, since the last release and I want to get it in 
time for the new release to be included into fpc 3.0.4. So, suddenly, I'm 
working on a whole lot more things on ptcpas (relative mouse movement, better 
unicode support for the keyboard input under both windows and linux, merging 
several other fixes into upstream fpc libraries, for which ptcpas carries a 
forked version) :) But, please be patient, it'll get there, maybe in a few 
week's time. If you're impatient, you can temporarily patch ptcgraph/ptccrt.pp, 
lines 120..309. 
These convert the ptcpas key events to crt readkey codes.

Best regards,
Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

I've just realized that the red and blue channels are reversed.  The sample
program aggpas_ptcgraph_output.pas has the star filled in with a red fade
and a blue series of random lines while the original test.png file had a
blue fade in the star with red random lines.   Also, the image is flipped on
the Y axis compared to the original example. The small green square is in
the upper left corner of test.png, but it is in the lower left corner of
aggpas_ptcgraph_output.pas

I've been able to duplicate the results of test.png by shifting the left 5
bits 11 positions to the right and the right 5 bits 11 positions to the left
and flipping the Y axis,  but I can only do that with putpixel and a nested
loop, which is quite a bit slower than putimage.   

Any ideas how I can build the data correctly so putimage will work?

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>   Also, the image is flipped on
>the Y axis compared to the original example. The small green square is in the 
>upper left corner of test.png, but it is in the lower left corner of 
>aggpas_ptcgraph_output.pas

It appears there is some ambiguity on whether 0,0 should be the lower left of 
upper left, but 
I figured out how to flip the image on the Y axis:

agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT, -(IMAGE_WIDTH * 
RGB_WIDTH)); 
makes the image what I would consider upside down because
agg^.rectangle(10, 10, 50, 50); 
ends up in the lower left corner but
ptcgraph.Rectangle(10,10,100,100);
ends up in the upper right corner.

If I use 
agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT, IMAGE_WIDTH * 
RGB_WIDTH);
now both 
agg^.rectangle(10, 10, 50, 50); 
and
ptcgraph.Rectangle(10,10,100,100);
end up in the upper left corner with the 10,10 coordinates matching up

I still have not figured out how to switch red and blue bits around so 
putimage() will work.

James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Tuesday, June 13, 2017 12:43 PM
To: 'FPC-Pascal users discussions' 
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

I've just realized that the red and blue channels are reversed.  The sample 
program aggpas_ptcgraph_output.pas has the star filled in with a red fade and a 
blue series of random lines while the original test.png file had a
blue fade in the star with red random lines.   Also, the image is flipped on
the Y axis compared to the original example. The small green square is in the 
upper left corner of test.png, but it is in the lower left corner of 
aggpas_ptcgraph_output.pas

I've been able to duplicate the results of test.png by shifting the left 5 bits 
11 positions to the right and the right 5 bits 11 positions to the left and 
flipping the Y axis,  but I can only do that with putpixel and a nested
loop, which is quite a bit slower than putimage.   

Any ideas how I can build the data correctly so putimage will work?

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal