Templot Club Archive 2007-2020                             

topic: 3563coding clips - December 2019
author remove search highlighting
 
posted: 2 Dec 2019 14:59

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Hi Graeme,

Bingo! :)

Or at least half a bingo.

When I found that Lazarus wouldn't accept

    Parent:=pad_form;

in the OnCreate event of a child form, I changed it to

   Windows.SetParent(Handle,pad_form.Handle);

Bad move. That's why it is grabbing the focus. After a bit of delving in Delphi I have discovered that Parent:= doesn't do that, it calls the InsertControl method on the parent. So what we need instead of SetParent is

  pad_form.InsertControl(the_child_form);

The end result is that no clicking or dragging on the child takes focus away from the parent, and all parent keyboard shortcuts work fine.

I said half a bingo, because it doesn't integrate the keyboard accelerator keys. To some extent that may be a good thing, in that we can have multiple child forms showing and not worry about accelerator conflicts. The actual functionality can be achieved by capturing keypresses on the parent, with a lot of iffing about which child forms are currently showing.

cheers,

Martin.

posted: 2 Dec 2019 15:43

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
The end result is that no clicking or dragging on the child takes focus away from the parent, and all parent keyboard shortcuts work fine.
Great news! Worth more than half a bingo, I would say. That deserves a 'Bing'!

I said half a bingo, because it doesn't integrate the keyboard accelerator keys. To some extent that may be a good thing, in that we can have multiple child forms showing and not worry about accelerator conflicts. The actual functionality can be achieved by capturing keypresses on the parent, with a lot of iffing about which child forms are currently showing.
er ... yes.  I THINK I understand this bit. It doesn't sound too disastrous. If I have understood it correctly, the parent is responsible for processing the accelerator keys of the children, yes?

When you say "... a lot of iffing ..." I assume you don't mean "iffing and blinding!".  :D

I just wondered what the 'Sender' parameter would contain. Is that a way to determine which child triggered the event (Sender.name), or does it always refer to the parent?

Anyway, still a good step forward (AND a teeny bit of Windows dependency avoided :)).

Cheers,

graeme






posted: 2 Dec 2019 16:13

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
er ... yes.  I THINK I understand this bit. It doesn't sound too disastrous. If I have understood it correctly, the parent is responsible for processing the accelerator keys of the children, yes?
Hi Graeme,

I was about to say yes when another Bingo happened. :)

The accelerator keys on the child work if the ALT key is held down, without needing to focus the form.

This may be something specific to my Windows settings (the ALT isn't needed here on focused Windows, nor on child forms in Templot2/Delphi).

It may be related to the pad KeyPreview settings and the existing key capture functions in pad_unit. More investigation needed.

I have rarely made much use of the Sender parameter, my guess is it would be the TButton on which the accelerator key appears. Do we need to use it? Just test for the key character and fire the relevant button. There is a lot of keyboard stuff in pad_unit, see the Tpad_form.FormKeyDown and Tpad_form.FormKeyPress event functions.

However, if ALT+key works on the child forms, we don't need to do anything else. 

cheers,

Martin.

posted: 3 Dec 2019 11:19

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
I have rarely made much use of the Sender parameter, .....
Hmmmm. It sounds as though I have misunderstood the problem (or perhaps invented one where none exists).

I was picturing a parent with two or more children who each had the same accelerator key and the parent had to deal with them, in the process trying to figure out which child's accelerator had been triggered.

If that's not the case under discussion, please ignore my babble.  :D

Cheers,

graeme


posted: 3 Dec 2019 11:59

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
I was picturing a parent with two or more children who each had the same accelerator key and the parent had to deal with them, in the process trying to figure out which child's accelerator had been triggered.
Hi Graeme,

In that case, yes you would need the Sender to separate the two.

But how do we (or Windows) know which one the user intended?

My solution has always been to hide one or other of the child forms while the other is showing.

But if ALT+accelerator works anyway, I think we could leave it at that.

The alternative is to ignore the Windows accelerator keys (do other platforms have similar?) and provide our own keyboard shortcuts for the buttons where we think they are most useful. Have you had a look at the shove_timber_form ? You see that I have repeated the accelerator key in upper case on some of the keys. If those key presses were implemented by the parent, there would be no reason to have them also underlined as Windows accelerator keys and it would work on all platforms.

For the other buttons, we can leave them as ALT+accelerator for users who need them for accessibility reasons, and everyone else can click them as usual.

cheers,

Martin.
Last edited on 3 Dec 2019 12:02 by Martin Wynne
posted: 8 Dec 2019 19:22

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
The second part - the switch info window - I will get to work on next.
Hi Graeme,

STOP!

There is no need to to anything on that. It is all working fine.

Perhaps I didn't explain properly that after removing  Windows.SetParent  and replacing it with

 // Windows.SetParent(data_child_form.Handle,pad_form.Handle);

   // 292...
 

 if data_child_form.Parent<>nil
    then data_child_form.Parent.RemoveControl(data_child_form);

 pad_form.InsertControl(data_child_form);

in all the applicable places, everything works fine as-is and as in Delphi. Focus remains always with the parent.

There are I think 4 places needed as above + 1 place (in math_unit) for

 switch_select_form.InsertControl(data_child_form);
                                          
instead.

But you don't need to upload those changes yourself because I have done it in your files.

Now we need the final code which all this was originally about -- if a background template is clicked while the data is showing, update the data automatically without waiting for its top menu item to be clicked.

cheers,

Martin.

posted: 9 Dec 2019 08:40

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
Graeme wrote:
The second part - the switch info window - I will get to work on next.
Hi Graeme,

STOP!

There is no need to to anything on that. It is all working fine.

Hi Martin,

I thought we also wanted to clone the data_child so that the switch info had a form of its own. :?

It seems a bit strange that showing switch info means you lose the template info. Or is that deliberate?

I realise this is not much of a change now, but I thought still desirable, no? :)

Cheers,

g



posted: 9 Dec 2019 09:41

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
Now we need the final code which all this was originally about -- if a background template is clicked while the data is showing, update the data automatically without waiting for its top menu item to be clicked.

Oooh yes - I do seem to recall some such idea. :D

Let me take a look.

(Can you post the latest code to SF for me to work on though, please. :) )

g




posted: 9 Dec 2019 10:35

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Hi Martin,

I seem to be missing a bgnd_shape_imageClick procedure, which is specified for the bgnd_shape_image OnClick event.

Is detection of a click on a backgrounded template is done some other way?

Cheers,

Graeme



posted: 9 Dec 2019 11:04

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
I thought we also wanted to clone the data_child so that the switch info had a form of its own. :?

It seems a bit strange that showing switch info means you lose the template info. Or is that deliberate?
Hi Graeme,

The primary reason for changing anything was that child forms as we had them were taking focus away from the parent. So that any dragging of them or clicking on them prevented the parent functioning, such as running up and down the lists on the arrow keys.

Having got the focus problem fixed, everything is working fine as before. So any changes now are additional functionality, not problem-fixes.

The child data form as it stands is used for 4 different things:

1. clicking the info button on the storage box.
2. clicking the view button on the info_form (itself a child window).
3. clicking the show info button on the switch settings.
4. (new) clicking the information menu items on the background templates popup. To which we may now be adding an automatic .click if the data is already showing.

I agree that it is not entirely logical to re-use the same form for all those, but on the other hand it has been working fine for years and IIABDFI. The problem was that we thought it was in fact B.

The switch info button is not used very often, probably never by many users, so the fact that it removes the data form from the pad hasn't been an issue. The switch settings form shows modal, so the other data couldn't in any case be used at the same time. At the time all this was designed, screen sizes were generally such that there wasn't room for both anyway.

We could perhaps add some code to restore it on the pad on closing the switch settings if it was showing there when swapped. On the other hand, at present if it's showing on the switch settings when closed, it is currently still there if opened again, which is probably useful. Users can easily restore it to the pad themselves if that is what's wanted.

p.s. it takes longer to write all this explanation than to make the actual code changes. Do other open-source projects find the same problem? It is the same and more so when writing the Help docs. If I had realised how much work that involved, I doubt I would ever have released Templot in the first place.

cheers,

Martin.

posted: 9 Dec 2019 11:20

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
Having got the focus problem fixed, everything is working fine as before. So any changes now are additional functionality, not problem-fixes.
Then I am inclined to leave it there. Missing functionality seems much more important.

I have come across a couple of pdf libraries and thought I might take a look at that next. Could you post the pdf_unit in reply to this, please?

Cheers,

graeme

PS
it takes longer to write all this explanation than to make the actual code changes. Do other open-source projects find the same problem? It is the same and more so when writing the Help docs. If I had realised how much work that involved, I doubt I would ever have released Templot in the first place.
Well, not just open source projects, but multi-person projects generally, open or closed. One of the biggest issues to overcome on any project is the number of communication channels (and I suppose this is not just in IT).

Of course it does improve as project members get more familiar with the code.

And yes, documentation just takes a  l o n g   t i m e.  :)




posted: 9 Dec 2019 11:46

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
I have come across a couple of pdf libraries and thought I might take a look at that next. Could you post the pdf_unit in reply to this, please
Hi Graeme,

I will have to look through that before posting it. The PDF engine licence does not allow me to publish any of the licensed stuff.

It is essentially a copy of print_unit with the Printer.Canvas changed to PDF.Canvas. It could have been the same unit for both, but there were a few details which needed to be different -- for example there is no calibration function for the PDF, ink intensity adjustment, banner option, support for ink-jet impact printers, etc.

The existing PDF engine is:

 http://www.wpcubed.com/pdf/products/wpdf/

for which I purchased the DCU option.

So any open-source replacement needs to offer the same functionality:

"With wPDF there is also a native canvas property of the type TCanvas. This also contains the property handle of type HDC. With this handle you can use Windows GDI commands."

I spent a long time looking for something, without success. :(

What we are essentially looking for is an EMF to PDF multi-page converter.

cheers,

Martin.

posted: 9 Dec 2019 12:02

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
I seem to be missing a bgnd_shape_imageClick procedure, which is specified for the bgnd_shape_image OnClick event.
Hi Graeme,

bgnd_shape_image is an invisible TImage component on the pad. It is used as a temporary TGraphic container for use in stretch-drawing background picture shapes on the pad.

Being invisible it doesn't have or need a click event, so I don't know where that came from. Maybe one of us accidentally double-clicked it on the pad_form design view? Just delete the reference.

I don't know why I didn't simply use a TGraphic alone -- almost certainly there was a reason, but I just can't remember it. :(  Anyway, IIABDFI.

p.s. it is not related in any way to the track templates. ???

cheers,

Martin.

posted: 9 Dec 2019 14:56

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
p.s. it is not related in any way to the track templates. ???
Hmmm - I had a strange feeling that might be the case.

So how DOES a click on the workpad get associated with a particular background template???  :?

Cheers,

graeme



Last edited on 9 Dec 2019 14:57 by Graeme
posted: 9 Dec 2019 15:03

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
Could you post the pdf_unit in reply to this, please?
Hi Graeme,

I have now been through it, removed a lot of stuff and inserted some rubbish, just to make it compilable, but don't try to actually use it.

All marked T3-OUT.

It does actually compile now when added to my project. Here's the unit file, form file next.

cheers,

Martin.
Attachment: attach_2953_3563_pdf_unit.pas     2

posted: 9 Dec 2019 15:04

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
and the form...
Attachment: attach_2954_3563_pdf_unit.lfm     3

posted: 9 Dec 2019 15:28

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
So how DOES a click on the workpad get associated with a particular background template??? 
Hi Graeme,

See in grid_unit:

 function hover_mousedown(click_x, click_y, limit:extended):integer;

There is only one call to it, in math_unit:

  function popup_if_clicked(ctrl_down,right_click:boolean):boolean;

  // popup and highlight bgnd keep if clicked on within limit g/2+1 (arbitrary)
  ...
  ...   clicked_keep_index:=hover_mousedown(mouse_x(pad_click_X),mouse_y(pad_click_X,pad_click_Y),g/2+1);
if clicked_keep_index=-1 then EXIT;    // not on one.


At which point you need to insert something along the lines of:

if showing_bgnd_template_data_on_the_pad then show_data_for_clicked_keep_index

cheers,

Martin.

posted: 10 Dec 2019 02:21

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
See in grid_unit: ...
Got it!

Thanks Martin.

graeme








posted: 10 Dec 2019 04:01

from:

Graeme
 
Bangkok - Thailand

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Martin Wynne wrote:
I have now been through it, removed a lot of stuff and inserted some rubbish, just to make it compilable, but don't try to actually use it.

All marked T3-OUT.

It does actually compile now when added to my project. Here's the unit file, form file next.

Hi, Martin,

Thanks for these. It turned out that the documentation for the libraries I found is ... er ... scant. Sigh. :roll:

Never mind. These things are sent to try us. I will see what I can do.

Cheers,

graeme



posted: 10 Dec 2019 05:20

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Attached below is a zip of a full set of my latest T3 files.

I will also put it in the Files section on SF.

For diffing and merging I use WinMerge (free) which is great:

 http://winmerge.org

The files include your changes, with a few additional changes from me. It is working fine here. :)

There is a new folder xml_units for the new BGS3 file format.

Zip below.

cheers,

Martin.
Attachment: attach_2955_3563_templot_mec_292a_10_12_2019.zip     2

posted: 12 Dec 2019 12:48

from:

Martin Wynne
 
West Of The Severn - United Kingdom

click the date to link to this post
click member name to view archived images
view images in gallery view images as slides
Graeme wrote:
You will send me changes based on one version of the software and I will apply it to mine, but mine will not be the same base as yours
Hi Graeme,

I don't see why that is a problem -- don't forget the TemplotMEC users.

There are 35 of us now in the "green" group. I want all of them to feel free to post ideas and perhaps unfinished bits of code. Then someone else can tidy it up and post here about how to insert it in their copy of Templot.

I guarantee that some of those ideas will be brilliant and well worth using. So we must encourage everyone to join in. If each of us ends up with their own version of Templot, so what? Why force everyone to use the same one?

Equally, some of the ideas may not be so appealing to me, and I want to be free not to use them if I don't want to, while not preventing anyone else from doing so.

All we need to agree is whose version is currently the best, to be uploaded as "Templot3" and linked on the Templot web site.

I have released a "first look" at Templot3 as part of Templot2 225c, plus I have posted the updated code on SF:

 topic 3571

cheers,

Martin.



Templot Club > Forums > TemplotMEC nuts and bolts > coding clips - December 2019
about Templot Club

Templot Companion - User Guide - A-Z Index Templot Explained for beginners Please click: important information for new members and first-time visitors.
indexing link for search engines

back to top of page


Please read this important note about copyright: Unless stated otherwise, all the files submitted to this web site are copyright and the property of the respective contributor. You are welcome to use them for your own personal non-commercial purposes, and in your messages on this web site. If you want to publish any of this material elsewhere or use it commercially, you must first obtain the owner's permission to do so.
The small print: All material submitted to this web site is the responsibility of the respective contributor. By submitting material to this web site you acknowledge that you accept full responsibility for the material submitted. The owner of this web site is not responsible for any content displayed here other than his own contributions. The owner of this web site may edit, modify or remove any content at any time without giving notice or reason. Problems with this web site? Contact webmaster@templot.com.   This web site uses cookies: click for information.  
© 2020  

Powered by UltraBB - © 2009 Data 1 Systems