[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 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
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 dont 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 windowtitle .
./src/macosx/graph.pp: windowTitle: CFStringRef;
./src/macosx/graph.pp: windowTitle := CFCopyLocalizedString(titleKey, nil);
// 5
./src/macosx/graph.pp: err := SetWindowTitleWithCFString (myMainWindow,
windowTitle); // 6
./src/macosx/graph.pp: CFRelease (windowTitle);
./src/win32/graph.pp:windowtitle : pchar = 'Graph window application';
./src/win32/graph.pp:
ParentWindow:=CreateWindowA('FPCGraphWindowMain', windowtitle,
./src/win32/graph.pp: hWindow:=CreateWindowA('FPCGraphWindow',
windowtitle,
Here you see that the Windows version simply uses CreateWindowA Windows API
function,
which means that you can use the Windows API function SetWindowTextA
to modify the title after starting (untested).
You will need the windows handle, but there is an interface variable
called GraphWindow that provides this for you.
> 3. Is there any way I can make my program use only the graph
> interface, and not display the command window?
Did you try
{$apptype gui}
or -WG option?
>
> Thanks for any advice anyone has to address these thing
I hope this will help you,
Pierre
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
On Wed, Aug 17, 2016 at 3:04 AM, Maciej Izak wrote:
>
> 2016-08-17 7:05 GMT+02:00 silvioprog :
>
>> Just try it:
>>
>
> related to
>
> http://bugs.freepascal.org/view.php?id=28911
>
> Sven comment: "I won't change the current implementation for now, because
> once I'm going to fix this I'm going to fix this correctly for all cases,
> including packages, everything else is merely a workaround. But for that I
> first need to finish my work on packages."
>
> btw, already reported: http://bugs.freepascal.org/view.php?id=30433
>
Indeed. After some debug I found where the exception is raised:
...
function TOpenAddressingLP.FindBucketIndex(constref
AItems: TArray;
constref AKey: TKey; out AHash: UInt32): SizeInt;
var
LItem: {TOpenAddressing.}_TItem; // for
workaround Lazarus bug #25613
LLengthMask: SizeInt;
i, m: SizeInt;
LHash: UInt32;
begin
m := Length(AItems);
LLengthMask := m - 1;
LHash := FEqualityComparer.GetHashCode(AKey); // << here
...
but I can't step into FEqualityComparer.GetHashCode to check why it
happens, so I'll wait for Sven too. ^^
I need to find the values using case-insensitive keys (I'm using it in a
class registry of my app), so unfortunately this bug doesn't let me to use
TDictionary on FPC yet. :-(
--
Silvio Clécio
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
2016-08-17 16:05 GMT+02:00 silvioprog : > I need to find the values using case-insensitive keys (I'm using it in a > class registry of my app), so unfortunately this bug doesn't let me to use > TDictionary on FPC yet. :-( There is simple workaround: === begin code === function EqualityComparison(constref ALeft, ARight: string): Boolean; begin Result := LowerCase(ALeft) = LowerCase(ARight); end; procedure ExtendedHasher(constref AValue: string; AHashList: PUInt32); begin TDefaultHashFactory.GetHashList(Pointer(AValue), Length(AValue) * SizeOf(Char), AHashList); end; var list: TDictionary; begin list := TDictionary.Create(TEqualityComparer.Construct(EqualityComparison, ExtendedHasher)); === end code === -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
Am 17.08.2016 08:05 schrieb "Maciej Izak" : > > > 2016-08-17 7:05 GMT+02:00 silvioprog : >> >> Just try it: > > > related to > > http://bugs.freepascal.org/view.php?id=28911 > > Sven comment: "I won't change the current implementation for now, because once I'm going to fix this I'm going to fix this correctly for all cases, including packages, everything else is merely a workaround. But for that I first need to finish my work on packages." > > btw, already reported: http://bugs.freepascal.org/view.php?id=30433 > Couldn't you work around for now by using instance instead of class variables? At least then the classes would work instead of everyone asking every second week why they don't... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
2016-08-17 17:20 GMT+02:00 Maciej Izak : > procedure ExtendedHasher(constref AValue: string; AHashList: PUInt32); > begin > TDefaultHashFactory.GetHashList(Pointer(AValue), Length(AValue) * > SizeOf(Char), AHashList); > end; > there is bug, correct version: procedure ExtendedHasher(constref AValue: string; AHashList: PUInt32); var temp: string; begin temp := LowerCase(AValue); TDefaultHashFactory.GetHashList(Pointer(temp), Length(temp) * SizeOf(Char), AHashList); end; -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
2016-08-17 17:15 GMT+02:00 Sven Barth : > Couldn't you work around for now by using instance instead of class > variables? At least then the classes would work instead of everyone asking > every second week why they don't... Yes I think that is possible :P Note: #28911 bug is most annoying ever (for generic programmers ;) ) -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted [Solved]
I think that I have now found why the test program below (originally
posted a couple of weeks ago) did not work. It seems that when an
interface is delegated, the compiler may take a reference directly on
the delegated part of the interface and not to the object doing the
delegation.
In my original post, the main procedure was:
procedure TDelegateTest.DoRun;
var Intf: IMyInterface;
Intf2: IMyInterface;
begin
Intf := TMyClass.Create(TDelegateClass.Create);
Intf2 := TDelegateClass.Create;
...
and the output showed that TMyClass was not being automatically
destroyed. Changing the local variables declaration to:
procedure TDelegateTest.DoRun;
var Intf: IUnknown;
Intf2: IMyInterface;
results in this output:
Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TMyClass
Destroying TDelegateClass
That is TMyClass is now being automatically destroyed, while the
TDelegateClass used to delegate the interface is not.
Changing the class definition to:
TMyClass = class(TInterfacedObject, IMyInterface)
private
FMyInterface: IMyInterface; // class type
property MyInterface: IMyInterface
read FMyInterface implements IMyInterface;
public
constructor Create(obj: TDelegateClass);
destructor Destroy; override;
end;
gives the output:
Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TMyClass
Destroying TDelegateClass
Destroying TDelegateClass
which is really what I wanted. On the other hand, if I change the
procedure header back to:
procedure TDelegateTest.DoRun;
var Intf: IMyInterface;
Intf2: IMyInterface;
begin
the output is now back to:
Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TDelegateClass
It seems that the main problem I had is due to the way the compiler
chooses which interface to reference count when you get an interface
from an object that has a delegated interface. If the type of the left
hand side of the assignment is that of the delegated interface, it
simply extracts that interface and only references it. On the other
hand, if it is any other compatible interface type (even IUnknown) then
the interface reference is to the object on the right hand side of the
assignment rather than to the delegated object.
This is probably a feature rather than a bug, but is certainly
confusing. It took me some time to get my head around it. The worst
thing is that I took the example from the FPC Documentation. The FPC
documentation on reference counting does not mention how it interacts
with delegated interfaces. It probably should.
Tony Whyman
MWA
On 10/08/16 13:42, Tony Whyman wrote:
I'm using fpc 3.0.0 and trying to debug a program using COM
interfaces. While reference counting seems to be working fine, there
is one exception, that is when an interface is being used by
delegation. In this case, the object doing the delegation does not
seem to be reference counted. Is this a bug, a feature, or have I
missed something?
A simple test program follows. The output is:
Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TDelegateClass
Destroying TDelegateClass
In the example, TMyClass is the interface class doing the delegation
and while TDelegateClass is being destroyed when it goes out of scope,
TMyClass is not.
Tony Whyman
MWA
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, SysUtils, CustApp
{ you can add units after this };
type
{ TDelegateTest }
TDelegateTest = class(TCustomApplication)
protected
procedure DoRun; override;
public
constructor Create(TheOwner: TComponent); override;
destructor Destroy; override;
procedure WriteHelp; virtual;
end;
IMyInterface = interface
procedure P1;
end;
{ TDelegateClass }
TDelegateClass = class(TInterfacedObject, IMyInterface)
private
procedure P1;
public
constructor Create;
destructor Destroy; override;
end;
{ TMyClass }
TMyClass = class(TInterfacedObject, IMyInterface)
private
FMyInterface: TDelegateClass; // class type
property MyInterface: TDelegateClass
read FMyInterface implements IMyInterface;
public
constructor Create(obj: TDelegateClass);
destructor Destroy; override;
end;
{ TDelegateClass }
procedure TDelegateClass.P1;
begin
writeln('P1');
end;
constructor TDelegateClass.Create;
begin
inherited Create;
writeln('Creating ',ClassName);
end;
destructor TDelegateClass.Destroy;
begin
writeln('Destroying ',ClassName);
inherited Destroy;
end;
{ TMyClass }
constructor TMyClass.Create(obj: TDelegateClass);
begin
inherited Create;
FMyInterface := obj;
writeln('Creating ',ClassName);
end;
destructor TMyClass.Destroy;
begin
writeln('Destroying ',ClassName);
inherited Destroy;
end;
{ TDelegateTest }
procedure TDelegateTest.DoRun;
var Intf: IMyInterface;
Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted [Solved]
On Wed, Aug 17, 2016 at 1:03 PM, Tony Whyman wrote: > I think that I have now found why the test program below (originally posted > a couple of weeks ago) did not work. It seems that when an interface is > delegated, the compiler may take a reference directly on the delegated part > of the interface and not to the object doing the delegation. > > In my original post, the main procedure was: > > procedure TDelegateTest.DoRun; > var Intf: IMyInterface; > Intf2: IMyInterface; > begin >Intf := TMyClass.Create(TDelegateClass.Create); >Intf2 := TDelegateClass.Create; > ... > > and the output showed that TMyClass was not being automatically destroyed. > Changing the local variables declaration to: > > procedure TDelegateTest.DoRun; > var Intf: IUnknown; > Intf2: IMyInterface; > > results in this output: > > Creating TDelegateClass > Creating TMyClass > Creating TDelegateClass > Destroying TMyClass > Destroying TDelegateClass > [...] So, in that way you will need to use 'cast' to work with Intf1 variable because it is not a IMyInterface type, right? Sounds like a workaround to me, not a good solution. Maybe I may have missed something, but I still think this is a bug. Best regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
On Wed, Aug 17, 2016 at 12:20 PM, Maciej Izak wrote: > > 2016-08-17 16:05 GMT+02:00 silvioprog : > >> I need to find the values using case-insensitive keys (I'm using it in a >> class registry of my app), so unfortunately this bug doesn't let me to use >> TDictionary on FPC yet. :-( > > > There is simple workaround: > > === begin code === > > function EqualityComparison(constref ALeft, ARight: string): Boolean; > begin > Result := LowerCase(ALeft) = LowerCase(ARight); > end; > > procedure ExtendedHasher(constref AValue: string; AHashList: PUInt32); > begin > TDefaultHashFactory.GetHashList(Pointer(AValue), Length(AValue) * > SizeOf(Char), AHashList); > end; > > var > list: TDictionary; > begin > list := TDictionary.Create(TEqualityCompar > er.Construct(EqualityComparison, ExtendedHasher)); > > === end code === > I changed it to a function: function ExtendedHasher(constref AValue: string): UInt32; begin TDefaultHashFactory.GetHashList(Pointer(AValue), Length(AValue) * SizeOf(Char), @Result); end; because the "Error: Incompatible type for arg no. 2: Got "ExtendedHasher(constref AnsiString;PDWord);", expected """. Anyway, thanks for the workaround, it can fix the FPC version of my tests. :-) -- Silvio Clécio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
2016-08-17 18:45 GMT+02:00 silvioprog : > I changed it to a function: > > function ExtendedHasher(constref AValue: string): UInt32; > begin > TDefaultHashFactory.GetHashList(Pointer(AValue), > Length(AValue) * SizeOf(Char), @Result); > end; > Still bad implementation (see my previous message). Is highly probable to obtain different hashes for 'foo' and 'Foo'. Usage of GetHashList in that context is also improper, GetHashList is generally dedicated for more complicated structures (for example for cuckoo hashing). The proper code is: function MyHasher(constref AValue: string): UInt32; var temp: string; begin temp := LowerCase(AValue); Result := TDefaultHashFactory.GetHashCode(Pointer(temp), Length(temp) * SizeOf(Char), 0); end; > because the "Error: Incompatible type for arg no. 2: Got > "ExtendedHasher(constref AnsiString;PDWord);", expected " variable type of function(constref AnsiString):DWord;Register>"". > > Point for you, that was code from my memory, sorry ;) ExtendedHasher in presented form is dedicated for TExtendedEqualityComparer.Construct(...) which is used for THashMap (THashMap is much faster than TDictionary for big data) -- Best regards, Maciej Izak ___ 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
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 dont 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
windowtitle .
./src/macosx/graph.pp: windowTitle: CFStringRef;
./src/macosx/graph.pp: windowTitle := CFCopyLocalizedString(titleKey, nil);
// 5
./src/macosx/graph.pp: err := SetWindowTitleWithCFStr
Re: [fpc-pascal] rtl-generics: TIStringComparer.Ordinal -> Access violation
Am 17.08.2016 17:30 schrieb "Maciej Izak" : > > > 2016-08-17 17:15 GMT+02:00 Sven Barth : >> >> Couldn't you work around for now by using instance instead of class variables? At least then the classes would work instead of everyone asking every second week why they don't... > > > Yes I think that is possible :P Note: #28911 bug is most annoying ever (for generic programmers ;) ) It's also very annoying to fix correctly (for compiler developers :P ) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
