headers
IvankoB | 1 Oct 2008 10:56
Picon
Favicon

Re: Proposal to file dialogues

>> Have a look into the dropdown window of 'Dir'. Normally there are + signs
>> in every row until the + has been clicked for opening the sub dir. With
>> fdo_checksubdir there are + signs in rows with sub directories only. I'll
>> add a special icon for non empty directories to tfilelistview.
> 
> Done, trunk 2498.

It dislpays plus-ed icons even for dirs containing only files (no 
subdirs ) that's misleading.
( provided that "plus" means "the directory can be traversed" )
Permalink | Reply | 3 comments |
headers
Martin Schreiber | 1 Oct 2008 12:18

Re: Proposal to file dialogues

IvankoB wrote:

>>> Have a look into the dropdown window of 'Dir'. Normally there are +
>>> signs in every row until the + has been clicked for opening the sub dir.
>>> With fdo_checksubdir there are + signs in rows with sub directories
>>> only. I'll add a special icon for non empty directories to
>>> tfilelistview.
>> 
>> Done, trunk 2498.
> 
> It dislpays plus-ed icons even for dirs containing only files (no
> subdirs ) that's misleading.
> ( provided that "plus" means "the directory can be traversed" )

The plus means the directory is not empty.
Permalink | Reply | 2 comments |
headers
IvankoB | 1 Oct 2008 13:23
Picon
Favicon

Re: Proposal to file dialogues

>> It dislpays plus-ed icons even for dirs containing only files (no
>> subdirs ) that's misleading.
>> ( provided that "plus" means "the directory can be traversed" )
> 
> The plus means the directory is not empty.

Then it contradicts to the meaning of the Dir pop-up - that's an 
inconsistence. It's better not to draw any pluses (as the M$ explorer 
does) than such mismatch.
Permalink | Reply | 0 comments |
headers
Graeme Geldenhuys | 1 Oct 2008 13:57
Picon

Re: Proposal to file dialogues

Martin Schreiber wrote:
>> It dislpays plus-ed icons even for dirs containing only files (no
>> subdirs ) that's misleading.
>> ( provided that "plus" means "the directory can be traversed" )
> 
> The plus means the directory is not empty.

I agree with IvankoB. That is weird behaviour. In any other application
in any OS, a plus means there are sub-directories. It normally has
nothing to do with the fact that the directory contains files or not.

Graeme.
Permalink | Reply | 0 comments |
headers
Martin Schreiber | 1 Oct 2008 14:03

Re: Proposal to file dialogues

IvankoB wrote:

>>> It dislpays plus-ed icons even for dirs containing only files (no
>>> subdirs ) that's misleading.
>>> ( provided that "plus" means "the directory can be traversed" )
>> 
>> The plus means the directory is not empty.
> 
> Then it contradicts to the meaning of the Dir pop-up - that's an
> inconsistence. It's better not to draw any pluses (as the M$ explorer
> does) than such mismatch.

The + means: "You will see more if you click here".
Permalink | Reply | 11 comments |
headers
Martin Schreiber | 1 Oct 2008 14:05

Re: Proposal to file dialogues

Graeme Geldenhuys wrote:

> Martin Schreiber wrote:
>>> It dislpays plus-ed icons even for dirs containing only files (no
>>> subdirs ) that's misleading.
>>> ( provided that "plus" means "the directory can be traversed" )
>> 
>> The plus means the directory is not empty.
> 
> I agree with IvankoB. That is weird behaviour. In any other application
> in any OS, a plus means there are sub-directories. It normally has
> nothing to do with the fact that the directory contains files or not.
> 
Do you talk about tdirdropdownedit or tfilelistview?

Martin
Permalink | Reply | 2 comments |
headers
IvankoB | 1 Oct 2008 14:25
Picon
Favicon

Re: Proposal to file dialogues

>>>> It dislpays plus-ed icons even for dirs containing only files (no
>>>> subdirs ) that's misleading.
>>>> ( provided that "plus" means "the directory can be traversed" )
>>> The plus means the directory is not empty.
>> Then it contradicts to the meaning of the Dir pop-up - that's an
>> inconsistence. It's better not to draw any pluses (as the M$ explorer
>> does) than such mismatch.
> 
> The + means: "You will see more if you click here".

Showing "here only files" is very useful too ;) Another marker for 
"files & no subdirs" ?
Permalink | Reply | 8 comments |
headers
Martin Schreiber | 1 Oct 2008 14:47

Re: Proposal to file dialogues

IvankoB wrote:

>>>>> It dislpays plus-ed icons even for dirs containing only files (no
>>>>> subdirs ) that's misleading.
>>>>> ( provided that "plus" means "the directory can be traversed" )
>>>> The plus means the directory is not empty.
>>> Then it contradicts to the meaning of the Dir pop-up - that's an
>>> inconsistence. It's better not to draw any pluses (as the M$ explorer
>>> does) than such mismatch.
>> 
>> The + means: "You will see more if you click here".
> 
> Showing "here only files" is very useful too ;) Another marker for
> "files & no subdirs" ?

Why not? Suggestions for the different icons? Size is 16*16 ;-)

Martin
Permalink | Reply | 7 comments |
headers
Domingo Alvarez Duarte | 1 Oct 2008 17:52
Picon

Re: Some issues that remain on win32

> Domingo Alvarez Duarte wrote:
> 
>> As well the issue with the XPS printer remain active, in theory XPS
>> printer appear to an application as another printer and should be
>> transparent to the application.
>>

Using this code I can print to XPS printer and get the expected result 
without problem.

procedure tmainfo.doPrintDirect(const sender: TObject);
var
	gdiprn : tgdiprinter;
	i : integer;
begin
	gdiprn := tgdiprinter.Create(nil);
	gdiprn.beginprint;
	for i := 0 to 100 do
	begin
		gdiprn.canvas.writeln('dadbiz ' + IntToStr(i));
	end;
	gdiprn.endprint;
	gdiprn.Destroy;
end;

I'm still investigating why msereport doesn't print correctly to XPS 
printer and images sometimes appear and sometimes doesn't.
Permalink | Reply | 11 comments |
headers
Martin Schreiber | 1 Oct 2008 18:04

Re: Some issues that remain on win32

Domingo Alvarez Duarte wrote:

>> Domingo Alvarez Duarte wrote:
>> 
>>> As well the issue with the XPS printer remain active, in theory XPS
>>> printer appear to an application as another printer and should be
>>> transparent to the application.
>>>
> 
> Using this code I can print to XPS printer and get the expected result
> without problem.
> 
IIRC you wrote the simplest repport (simple text, no images, no lines)
prints nothing on XPS. Probably the most important difference between
treport and your test are clipping regions. Could you test if clipping
works with direct XPS printing?

Martin
Permalink | Reply | 10 comments |

Gmane