[SOLVED]TSelectDirectoryDialog has a couple of issues, maybe more.

[jamie]

First off:
   
    The Dialog does not scroll to view when it is initially showed, you have to scroll
down to the initial folder where it is high lighted like it should be, but how to get it
to scroll to that position when the dialog shows?

Second:
   
   I decided to attempt to send the TVM_ENSUREVISIBLE message to the Treeview
 control in it, so the OnShow event is the best place for that. When doing so, I
 found out this event triggers after the dialog closes and not on initial showing of it?

  I have not tested the OnClose?

  Can someone shed a little light on this please?

 Windows 10, using 1.6.4
 

[wp]

The Dialog does not scroll to view when it is initially showed, you have to scroll
down to the initial folder where it is high lighted like it should be, but how to get it
to scroll to that position when the dialog shows?

Are you using the TSelectDirectoryDialog from the component palette? This one comes up as the new-style dialog which looks like the FileOpen dialog (which is a bit strange at first) and does not have this issue. You can switch back to the old dialog by setting the option ofOldStyleDialog - then it shows the issue that you describe, but I think this has been a general annoyance of Windows for along time, I've seen it in many non-Lazarus programs.

[jamie]

There is something seriously wrong with it.

 I don't have the OldStyle (Checked) or showing and it does show the new style of
view.
 
 Most of the events for it do not fire.. the OnSHow does fire but after you close it.

[wp]

Even if the new-style dialog is selected, the attached demo shows the old-style dialog exactly as you report if I use Laz 1.6.4. But with Laz 1.8RC5 the new-style dialog opens, and it has all events. But even with 1.8 I get the buggy behavior like you if the old-style dialog is activated.

As I said before, the buggy old-style dialog is a Windows issue (in my opinion) because I've seen it with many programs certainly not written by Lazarus.

[jamie]

Ok, but like I said before, I am not using the oldstyle settings, by setting that
property to oldstyle all I get is the same results with a reduce functional dialog box

 The problem appears to be the message handling, the OnShow over here works
after the fact and thus must be holding up the rest of the message events.

 I implemented the BrowseForFolder from the API and that works as expected.

 Not sure where the code went wrong, I suppose I could look at it but something
tells me there maybe a Application.ProcessMessages inserted in there somewhere
which is the wrong thing to do.
 Oh well, move on I guess.

[JuhaManninen]

You use Lazarus 1.6.4. Switch to 1.8 and the problem is solved.

[ASerge]

A bug in Windows, starting with Windows 7.
In TSelectDirectory.Options, exclude ofEnableSizing. Given the desire to call the old form of dialog selection, the option ofOldStyleDialog should be selected.

[jamie]

I got around today to try out 1.8.x since it has a official release tag.

 I Installed the windows 64 bit version first to try out some pre-existing code I
made with 1.6.4.

 The SelecctDirectoryDialog now seems to work for the Onshow event and others and
also now shows the actual file manager that Windows 10 is using..

 However!

    Compiling a large project I have "Post script engine", compiles error free but,,
fails on multiple turns of different post script files I try out that work find with the
1.6.4 laz... 
 so I turned on the HeapTrc, it reports no leaks.. ok, Fine..

 so I then change the optimizer from  1(where I usually have it) to 4 just for kicks,.
 it compiles and my code works fine .....?
 
 But!, when I exit, the HeapTrc tells me I have leaks in a certain section I never had
before... ?

 I will dig deeper but something is telling me there is an issue with the Fpc compiler?

 P.S.
  I down loaded this twice....

[Thaddy]

so I then change the optimizer from  1(where I usually have it) to 4 just for kicks,.
 it compiles and my code works fine .....?
 
 But!, when I exit, the HeapTrc tells me I have leaks in a certain section I never had
before... ?

Heaptrc can not do its job when the optimization level is higher than O1 or O2. That is documented.
But you can assume that if heaptrc finds anything without overly optimizing, the subsequent binary compiled in O4 will also not leak.

A matter of reading documentation carefully. (I am rather proud of my restraint  )
Note that if you were really stupid and included heaptrc in the uses clause, you are beyond help.
You should use the compiler settings for that or the command line option.

[jamie]

Really? is that your position?

 For the record I did not include the HeapTrc unit in the uses clause.

 I used the provided UI lazarus provides which is part of the project settings.

 You claim there is documentation of the inability of heapTrc not properly functioning
 in opt mode 4? I am not debating that. It's the first for me since I've never had any issues with it in level 4, it has always reported a clean checkout when I had no leaks, and otherwise report leaks at any level.

 But I will say this, I just did a ASM code comparison with 3.0.4 output verses what the official 1.6.4 was using, and there is a difference in a problem section that I have identified using the same Op-Level.

 Please reframe from your insults, I present things as I find them from using my 43+ years of experience starting with punch card systems, 4 bit Cpu's and up. I can recognize an issue when I see one..

 
 
 

 

[wp]

Note that if you were really stupid and included heaptrc in the uses clause, you are beyond help.

Thaddy, your insulting posts are hardly bearable any more...

[balazsszekely]

Thaddy, your insulting posts are hardly bearable any more...

@wp
I think you're take it too seriously. Thaddy is the mascote of the free pascal community.  Now don't get me wrong, he knows he's stuff better then I ever will, but still he choose to behave like a five year old child. I find he's comments funny. Grumpy mode on < > 

[jamie]

I got the compiler to final compile and run that large app without issues in any
optimization level.

  I didn't find any error in my code and I placed a lot of Asserts in there to
find suspected issues. The Errors I was getting were strange in deed however, I
noticed after I had every one of the source files open in the IDE belonging to the
project one edit window at a time, doing BUILDS, all the problems went away,,.

 It seems like on the EDIT tab that was visible was being updated correctly because
the error would move on to another chunk of code which was in another unit..

 The only thing I can conclude from this is some configuration of building the project
wasn't correct but I got it working now and all seems to be well for that matter.

 There are other issues found with 1.8.0 but we won't go there in this thread.

Thanks