Date   

Re: XPA differences - Range/Locate/Key switching in the GUI

Peter Ashworth
 

Hi Steven

b. Unfortunately not, in an ideal world every visible table field would start with t_ but it was never a need before to ever identify fields like this.
d. We do have this in a fair few places, but things like our generic table browses were just intended for use with the built in range/locate etc
e. did you generally disable it and only allow certain programs to fire it, or is it just always there but you have visible filter buttons to prevent its use by a user?

I'm currently in 3.3g in development but we've been told they are no longer doing a hand in hand development of 3.3 and 4.6 and we should move to 4.6 when we can. There was a lot wrong with 2.5, the main killing point for us was that they did away with the main program form. Took a lot of "negotiation" to get them to bring it back. I'm guessing we weren't the only ones fighting for it.

As you say its not end of the world not having it, and it will really only effect a few super users and troubleshooters. Some of which we might work around by just letting it be enabled for people with a particular right, and cleaning up the variable names for the most frequently used programs.

Thanks

Peter


Re: XPA differences - Range/Locate/Key switching in the GUI

Steven Burrows
 

It’s a bit of everything.

We still use UserFunctionality but is :

  1. Modified to fit our GUI
  2. Tinkered with to exclude variables we don’t want the user to access, easy enough by checking VarName(). You do have a good naming convention ? 😉
  3. Whole chunks of functionality disabled (e.g. Print) just because it causes more grief than it solves
  4. Our Application Forms now have useful range and index options hard coded. Better that way, it shows the user sensible things to use, and they can be optimised. Normally only a couple of text ranges, a few check box ranges (e.g. show complete, show incomplete), and a Radio/Drop Down with Sort options. Its not a lot of work, and not mandatory for all programs immediately, upgrade them as & when.
  5. Ctrl-R/L/Sort still available for when our options are not enough

 

Are looking at 4.6 ? It’s brilliant compared to 2.5 which we are only now about to abandon. 2.5 didn’t have ANY “View by Key “ functionality. We had to apply our own options and/or turn on Column Sorting. It took a while, but we eventually didn’t miss it being totally absent.

 

It is different, but its not that bad, you and your users WILL get used to it fairly quickly, and it now has some really funky things in (Print to Excel Graph looks like a doozy)

 

Steven Burrows

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of Peter Ashworth via Groups.Io
Sent: 26 March 2020 17:31
To: main@magicu-l.groups.io
Subject: [magicu-l] XPA differences - Range/Locate/Key switching in the GUI

 

This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.

 

Hi all

For a long while our project has been in Magic 9 and we are slowly but surely pushing into XPA. A thing we use, I suppose mostly for troubleshooting but it has other uses, is the ctrl+r ctrl+l and ctrl+k commands.

This worked really nicely in Magic 9 because it was interlaced into the visible table and you could just enter your range or locate into the column you were interested in. However now the functionality is gone, with a sort of replacement in the UserFunctionalityComponent.

It seems like a step back in functionality for existing projects, new projects you can always code with it in mind I suppose. Now its a popup window, with all of the virtual variable names in the task listed as selectable values even if they are static and not in the table. And as such a lot of these variables are named from a developer perspective and aren't friendly to be displayed to the user.

I've read there is options to by default don't expose anything to the range window and instead you can add a flag indicator to specific virtuals to allow them to be exposed. However to do that would be an extremely manual process.

Also I've noticed the keys window always defaults to key 1 even if the current key in use is something else, which isn't very helpful as we used to use this fairly often to tell us what key a program was using when troubleshooting at a site, without having to reference back to the code, and dig through logic if its a dynamically selected key.

Whats been every ones thoughts on this? Has there been any tweaking or working around of this/alternative approaches? Or is the accepted thinking now that you actually write a GUI screen to handle filtering of specific fields in a view?

Another thing we might try, although its not an ideal approach, is to load the user functionality component, but try and suppress calls to it other then specific support/super users.

Thanks

Peter

PS Hope all is well with everyone


XPA differences - Range/Locate/Key switching in the GUI

Peter Ashworth
 

Hi all

For a long while our project has been in Magic 9 and we are slowly but surely pushing into XPA. A thing we use, I suppose mostly for troubleshooting but it has other uses, is the ctrl+r ctrl+l and ctrl+k commands.

This worked really nicely in Magic 9 because it was interlaced into the visible table and you could just enter your range or locate into the column you were interested in. However now the functionality is gone, with a sort of replacement in the UserFunctionalityComponent.

It seems like a step back in functionality for existing projects, new projects you can always code with it in mind I suppose. Now its a popup window, with all of the virtual variable names in the task listed as selectable values even if they are static and not in the table. And as such a lot of these variables are named from a developer perspective and aren't friendly to be displayed to the user.

I've read there is options to by default don't expose anything to the range window and instead you can add a flag indicator to specific virtuals to allow them to be exposed. However to do that would be an extremely manual process.

Also I've noticed the keys window always defaults to key 1 even if the current key in use is something else, which isn't very helpful as we used to use this fairly often to tell us what key a program was using when troubleshooting at a site, without having to reference back to the code, and dig through logic if its a dynamically selected key.

Whats been every ones thoughts on this? Has there been any tweaking or working around of this/alternative approaches? Or is the accepted thinking now that you actually write a GUI screen to handle filtering of specific fields in a view?

Another thing we might try, although its not an ideal approach, is to load the user functionality component, but try and suppress calls to it other then specific support/super users.

Thanks

Peter

PS Hope all is well with everyone


Re: dotnet SyncFusion sfDataGrid.net coponent #xpa3.3

Adrian Wick
 
Edited

I got it working. I missed the part that in 3rd Party Samples the grid is put on the form as a Model and in that model there were a few options i was missing.
I made a similar model for sf data grid and it works now.

Thank you anyways.

Regards,
Adrian


transaction file #ria

Ryan Guedes <ryanguedes2010@...>
 

Hi guys
I know that the transactions have a temporary transaction file and I wanted more details about this file, does it have a folder? how can I access it?
Thank you for your attention.


Connection is busy with results for another command

Wilver Gonzalez
 

Hello everyone, i'm passing time trying to fix a problem.
 
The problem is "Connection is busy with results for another command" and getting crazy to fix it. 
 
Has anyone had this same problem? or does anyone know how I can fix it?
 
I would be really grateful if you could help me. I am using a SQL Server Database this service is provided by Amazon (AWS)


XPA 3.3 Online prog to XPA 4.x Web Client

 

Hi guys,

I would like to know what would be the advantages or disadvantages in converting my existing project with Online programs to Web Client?

Does this affect the database/data tables?

Thanks in advance!


Re: dotnet SyncFusion sfDataGrid.net coponent #xpa3.3

Wilver Gonzalez
 
Edited

Hi, Adrian

We can see the code or someting else? To understand which is the problem?


Re: Warning : big bug on delete status in XPA 4.6 #xpa4.6

Sébastien GT
 

Magic tell me today that : Magic will release tomorrow a new version for everybody ;-)


Re: Warning : big bug on delete status in XPA 4.6 #xpa4.6

Sébastien GT
 

Yes, Magic made a version only for my company.
I informed them that this bug affected everyone.
The new version completely corrects this deletion bug.


Re: Warning : big bug on delete status in XPA 4.6 #xpa4.6

Steven Burrows
 

Is this an “on request” release ? Cant see it on Downloads page.

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of Sébastien GT via Groups.Io
Sent: 19 March 2020 10:49
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Warning : big bug on delete status in XPA 4.6 #xpa4.6

 

Good morning all,

Magic will release today or tomorrow a new Magic XPA 4.6.1a version that fixes this bug.


Re: XPA 3.2e Form Editor problems

Idris
 

thank you Wes... this saved or rather gave me a new life today :) 


dotnet SyncFusion sfDataGrid.net coponent #xpa3.3

Adrian Wick
 

Hello all,

1st of all i realy hope you and your families are safe and healthy!!! Now to my question regarding dotnet 3rd party samples.

In online samples, there are a few examples of how to use 3rd parties dot.net components. I am talking about the DevExpress examples and data binding.

SyncFusion is similar to DevExpress ... But for some reason whenever i try to bind data to sfDataGrid component, program crashes ... I have fallowed
their instruction and added all the components needed here:
https://help.syncfusion.com/windowsforms/datagrid/gettingstarted

and added everything here:
https://help.syncfusion.com/windowsforms/control-dependencies#sfdatagrid

i added Syncfusion.WinForms.DataGrid.SfDataGrid.net and put it on the form. Its odd, cause the component shows nothing compared to DevExpress
in which the whole table is already drawn and shown ... And as soon as i add columns in .net properties, program starts to crash ... If no columns are
selected, the form opens, but its empty. Am i missing something? 

Thank you and best regards,
Adrian


Heads up, XPA v4 Single User available for download

przemm@...
 

Hi Everyone,

I've noticed that MSE offers now XPA4.6 when you download Single User version .

Hope it will be of interest for some of you.

Take care of yourself, good health !
Przemek


Re: Printing multiiple lines on a standardized form

sherman levine
 

I have so much of the form written that I think I'll just go with one RTF edit control per record. I can generate all the data in a memory table including the formatted text and the page# and line#, so all I need to do with the form is read the table and output the text.  If I use a color with a transparent background for the controls, I can even make vertical lines go cleanly thru the table.

People will live with the Courier font. I'll tell them it's "Classic" :-)

On 3/22/2020 11:55 AM, Keith Canniff wrote:

Sherm,

 

Yeah Fixed Size = No will give you only a table the height of the actual rows populated and will cause everything around it to move.

 

As for the text around the table. You can’t

  1. Define an RTF (or on RTF) control that’s certain fixed height and width and have it do word wrap? Obviously it has to be large enough to handle the total text you’re going to have. It will a text field’s size (let’s say 100) and then init it with 100 “W”s to see if the control is large enough to handle the maximum content.

 

So you have a fixed size table and a fixed size control… both than can contain a varying about of data. This should keep the form from adjusting its size.

 

I’ve had some fairly complex full page forms in the past that I’ve been able to consistently put out the same form. So much so that the were used to import into an OCR scan where the data had to remain in the same areas for it to pick up certain information.

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 9:18 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith

 

Fix size table=Yes works perfectly, but ends up with a blank are where I need to put the section for totals (which need to follow the details, and only on the last page). 

 

Fix size table=No is funky - and I suspect the problem relates to the text controls which are alongside the table.

If I print with an 8" vertical form, the form actually expands vertically beyond 8" (with a blank area at the bottom).  Magic has always had a problem dealing with vertically expanding controls (in this case the table) next to other controls, and this is probably just another example.

 

Probably simplest for me to limit myself to fixed-width text and go the RTF route

 

Thanks for your help. 

 

Sherm

 

On 3/22/2020 8:45 AM, Keith Canniff wrote:

Sherm,

 

Try the following. From the Data Repository do a Ctrl+G on your table, tell it to generate a “Print” output. Not sure if 9.4 did this but XPA will generate an output with a table control in a form, but I’m sure you have a copy of XPA around you could do this with just to verify

 

I would then:

  • expand the form (Change to inches from Dialog Units, and make it 8.5 x 11… or the Dialog Unit equivalent)
  • expand the table size to the 9 rows you want
  • change the table control properties to “Fix size table = Yes”
  • Move the table on the form approximately where you want it before entering all the other fields around it
  • Change the output to Preview so you can see it on the screen
  • Run it

 

You should get the desired output… at least you do in XPA.

 

Note: There should only be one form and it should be a “Detail” area and Expand Form = No

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 5:34 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith,

 

Thanks. Got it working

 

Output form needed to be set to Auto instead of Top (of course)

 

Also I needed to set table height to fixed, otherwise it would print just 2 records per page and pull the bottom text up to below the 2-record table instead of at the bottom of the page. I might be able to handle the text shift via a separate form, but I'm not sure why it printed just 2 records per page.  Any thoughts?

 

Sherm

 

On 3/21/2020 11:17 PM, sherman levine wrote:

Just tried it (not much to do here these days).

Gives me one record per page.

Sherm

 

On 3/21/2020 10:49 PM, Sherman Levine wrote:

Really? I’ll give that a try tomorrow. 

Thanks

Sherm

 




On Mar 21, 2020, at 22:35, Keith Canniff <kcanniff@...> wrote:



Sherrm

You should be able to define the entire page as a single form with a table control in the middle just like an online screen.

The table control has 7 columns in it.

If you have less than 9 records the remainder of the 9 rows will be blank and so any fields outside the table will print in the same location

If there are more than 9 items then Magic will automatically start a new page with table continuing from record 10-19 and so on.

Is that what you're looking for?

Keith


From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of sherman levine <sherman.levine@...>
Sent: Saturday, March 21, 2020 10:11:09 PM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: [magicu-l] Printing multiiple lines on a standardized form

 

This is a 9.4 question, but I suspect it's still relevant to newer releases.

I have a form (in this case a Bill of Lading) which includes a fixed
height table plus lots of fixed text above, to the right, and below the
table.

  In this case, the table consists of up to 9 line items, each of which
has 7 fields.

Now, I've handled this in the past by putting 63 virtuals on the form, 
populating them by scanning a table and doing a bunch of varsets (in
this case 7) for each of the 9 line items, then printing the page etc.

It works, but lacks grace and elegance.

An alternative approach is to use 9 RTF edit controls, and synthesize
one RTF string for each line item.  That actually works quite nicely. I
can mix font sizes and styles, but I'm limited to fixed-width fonts if I
want the columns to align. (For those who want to try this, its easiest
to build a test line as a RTF text control, export the Magic task, and
see what the Magic-acceptable RTF looks like, then copy and replace)

I was wondering if anybody had found a better solution.

Thanks

Sherm





 

 

 

Virus-free. www.avast.com

 



Re: Printing multiiple lines on a standardized form

Keith Canniff
 

Sherm,

 

Yeah Fixed Size = No will give you only a table the height of the actual rows populated and will cause everything around it to move.

 

As for the text around the table. You can’t

  1. Define an RTF (or on RTF) control that’s certain fixed height and width and have it do word wrap? Obviously it has to be large enough to handle the total text you’re going to have. It will a text field’s size (let’s say 100) and then init it with 100 “W”s to see if the control is large enough to handle the maximum content.

 

So you have a fixed size table and a fixed size control… both than can contain a varying about of data. This should keep the form from adjusting its size.

 

I’ve had some fairly complex full page forms in the past that I’ve been able to consistently put out the same form. So much so that the were used to import into an OCR scan where the data had to remain in the same areas for it to pick up certain information.

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 9:18 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith

 

Fix size table=Yes works perfectly, but ends up with a blank are where I need to put the section for totals (which need to follow the details, and only on the last page). 

 

Fix size table=No is funky - and I suspect the problem relates to the text controls which are alongside the table.

If I print with an 8" vertical form, the form actually expands vertically beyond 8" (with a blank area at the bottom).  Magic has always had a problem dealing with vertically expanding controls (in this case the table) next to other controls, and this is probably just another example.

 

Probably simplest for me to limit myself to fixed-width text and go the RTF route

 

Thanks for your help. 

 

Sherm

 

On 3/22/2020 8:45 AM, Keith Canniff wrote:

Sherm,

 

Try the following. From the Data Repository do a Ctrl+G on your table, tell it to generate a “Print” output. Not sure if 9.4 did this but XPA will generate an output with a table control in a form, but I’m sure you have a copy of XPA around you could do this with just to verify

 

I would then:

  • expand the form (Change to inches from Dialog Units, and make it 8.5 x 11… or the Dialog Unit equivalent)
  • expand the table size to the 9 rows you want
  • change the table control properties to “Fix size table = Yes”
  • Move the table on the form approximately where you want it before entering all the other fields around it
  • Change the output to Preview so you can see it on the screen
  • Run it

 

You should get the desired output… at least you do in XPA.

 

Note: There should only be one form and it should be a “Detail” area and Expand Form = No

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 5:34 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith,

 

Thanks. Got it working

 

Output form needed to be set to Auto instead of Top (of course)

 

Also I needed to set table height to fixed, otherwise it would print just 2 records per page and pull the bottom text up to below the 2-record table instead of at the bottom of the page. I might be able to handle the text shift via a separate form, but I'm not sure why it printed just 2 records per page.  Any thoughts?

 

Sherm

 

On 3/21/2020 11:17 PM, sherman levine wrote:

Just tried it (not much to do here these days).

Gives me one record per page.

Sherm

 

On 3/21/2020 10:49 PM, Sherman Levine wrote:

Really? I’ll give that a try tomorrow. 

Thanks

Sherm

 




On Mar 21, 2020, at 22:35, Keith Canniff <kcanniff@...> wrote:



Sherrm

You should be able to define the entire page as a single form with a table control in the middle just like an online screen.

The table control has 7 columns in it.

If you have less than 9 records the remainder of the 9 rows will be blank and so any fields outside the table will print in the same location

If there are more than 9 items then Magic will automatically start a new page with table continuing from record 10-19 and so on.

Is that what you're looking for?

Keith


From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of sherman levine <sherman.levine@...>
Sent: Saturday, March 21, 2020 10:11:09 PM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: [magicu-l] Printing multiiple lines on a standardized form

 

This is a 9.4 question, but I suspect it's still relevant to newer releases.

I have a form (in this case a Bill of Lading) which includes a fixed
height table plus lots of fixed text above, to the right, and below the
table.

  In this case, the table consists of up to 9 line items, each of which
has 7 fields.

Now, I've handled this in the past by putting 63 virtuals on the form, 
populating them by scanning a table and doing a bunch of varsets (in
this case 7) for each of the 9 line items, then printing the page etc.

It works, but lacks grace and elegance.

An alternative approach is to use 9 RTF edit controls, and synthesize
one RTF string for each line item.  That actually works quite nicely. I
can mix font sizes and styles, but I'm limited to fixed-width fonts if I
want the columns to align. (For those who want to try this, its easiest
to build a test line as a RTF text control, export the Magic task, and
see what the Magic-acceptable RTF looks like, then copy and replace)

I was wondering if anybody had found a better solution.

Thanks

Sherm





 

 

 

Virus-free. www.avast.com

 


Re: Printing multiiple lines on a standardized form

sherman levine
 

Ariel,
Thank you. That might work for a preprinted form, but I need to generate the full-page form in Magic, and it includes a column of fixed text to the right of the table area.  If I don't use a table (as Keith suggested) then I only get one record per printed page, regardless of the Records per Page entry.
Sherm


On 3/22/2020 9:26 AM, Mr Magic via Groups.Io wrote:
Do you looking for this maybe - 

CTRL+C 
Behavior

Records Per Page
The Records Per Page property is used to produce reports on pre-printed forms, where the header and footer are in a fixed position and a fixed number of lines exist on each page. In this case, a fixed number of records should be output to each page, with the last page padded with empty lines.


hope this help 

Ariel Kotler - Magic Line
www.magicline.co.il


On Sunday, March 22, 2020, 3:18:47 PM GMT+2, sherman levine <sherman.levine@...> wrote:


Keith

Fix size table=Yes works perfectly, but ends up with a blank are where I need to put the section for totals (which need to follow the details, and only on the last page). 

Fix size table=No is funky - and I suspect the problem relates to the text controls which are alongside the table.
If I print with an 8" vertical form, the form actually expands vertically beyond 8" (with a blank area at the bottom).  Magic has always had a problem dealing with vertically expanding controls (in this case the table) next to other controls, and this is probably just another example.

Probably simplest for me to limit myself to fixed-width text and go the RTF route

Thanks for your help. 

Sherm

On 3/22/2020 8:45 AM, Keith Canniff wrote:

Sherm,

 

Try the following. From the Data Repository do a Ctrl+G on your table, tell it to generate a “Print” output. Not sure if 9.4 did this but XPA will generate an output with a table control in a form, but I’m sure you have a copy of XPA around you could do this with just to verify

 

I would then:

  • expand the form (Change to inches from Dialog Units, and make it 8.5 x 11… or the Dialog Unit equivalent)
  • expand the table size to the 9 rows you want
  • change the table control properties to “Fix size table = Yes”
  • Move the table on the form approximately where you want it before entering all the other fields around it
  • Change the output to Preview so you can see it on the screen
  • Run it

 

You should get the desired output… at least you do in XPA.

 

Note: There should only be one form and it should be a “Detail” area and Expand Form = No

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 5:34 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith,

 

Thanks. Got it working

 

Output form needed to be set to Auto instead of Top (of course)

 

Also I needed to set table height to fixed, otherwise it would print just 2 records per page and pull the bottom text up to below the 2-record table instead of at the bottom of the page. I might be able to handle the text shift via a separate form, but I'm not sure why it printed just 2 records per page.  Any thoughts?

 

Sherm

 

On 3/21/2020 11:17 PM, sherman levine wrote:

Just tried it (not much to do here these days).

Gives me one record per page.

Sherm

 

On 3/21/2020 10:49 PM, Sherman Levine wrote:

Really? I’ll give that a try tomorrow. 

Thanks

Sherm

 



On Mar 21, 2020, at 22:35, Keith Canniff <kcanniff@...> wrote:



Sherrm

You should be able to define the entire page as a single form with a table control in the middle just like an online screen.

The table control has 7 columns in it.

If you have less than 9 records the remainder of the 9 rows will be blank and so any fields outside the table will print in the same location

If there are more than 9 items then Magic will automatically start a new page with table continuing from record 10-19 and so on.

Is that what you're looking for?

Keith


From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of sherman levine <sherman.levine@...>
Sent: Saturday, March 21, 2020 10:11:09 PM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: [magicu-l] Printing multiiple lines on a standardized form

 

This is a 9.4 question, but I suspect it's still relevant to newer releases.

I have a form (in this case a Bill of Lading) which includes a fixed
height table plus lots of fixed text above, to the right, and below the
table.

  In this case, the table consists of up to 9 line items, each of which
has 7 fields.

Now, I've handled this in the past by putting 63 virtuals on the form, 
populating them by scanning a table and doing a bunch of varsets (in
this case 7) for each of the 9 line items, then printing the page etc.

It works, but lacks grace and elegance.

An alternative approach is to use 9 RTF edit controls, and synthesize
one RTF string for each line item.  That actually works quite nicely. I
can mix font sizes and styles, but I'm limited to fixed-width fonts if I
want the columns to align. (For those who want to try this, its easiest
to build a test line as a RTF text control, export the Magic task, and
see what the Magic-acceptable RTF looks like, then copy and replace)

I was wondering if anybody had found a better solution.

Thanks

Sherm




 

 


Virus-free. www.avast.com




Re: Printing multiiple lines on a standardized form

Mr Magic
 

Do you looking for this maybe - 

CTRL+C 
Behavior

Records Per Page
The Records Per Page property is used to produce reports on pre-printed forms, where the header and footer are in a fixed position and a fixed number of lines exist on each page. In this case, a fixed number of records should be output to each page, with the last page padded with empty lines.


hope this help 

Ariel Kotler - Magic Line
www.magicline.co.il


On Sunday, March 22, 2020, 3:18:47 PM GMT+2, sherman levine <sherman.levine@...> wrote:


Keith

Fix size table=Yes works perfectly, but ends up with a blank are where I need to put the section for totals (which need to follow the details, and only on the last page). 

Fix size table=No is funky - and I suspect the problem relates to the text controls which are alongside the table.
If I print with an 8" vertical form, the form actually expands vertically beyond 8" (with a blank area at the bottom).  Magic has always had a problem dealing with vertically expanding controls (in this case the table) next to other controls, and this is probably just another example.

Probably simplest for me to limit myself to fixed-width text and go the RTF route

Thanks for your help. 

Sherm

On 3/22/2020 8:45 AM, Keith Canniff wrote:

Sherm,

 

Try the following. From the Data Repository do a Ctrl+G on your table, tell it to generate a “Print” output. Not sure if 9.4 did this but XPA will generate an output with a table control in a form, but I’m sure you have a copy of XPA around you could do this with just to verify

 

I would then:

  • expand the form (Change to inches from Dialog Units, and make it 8.5 x 11… or the Dialog Unit equivalent)
  • expand the table size to the 9 rows you want
  • change the table control properties to “Fix size table = Yes”
  • Move the table on the form approximately where you want it before entering all the other fields around it
  • Change the output to Preview so you can see it on the screen
  • Run it

 

You should get the desired output… at least you do in XPA.

 

Note: There should only be one form and it should be a “Detail” area and Expand Form = No

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 5:34 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith,

 

Thanks. Got it working

 

Output form needed to be set to Auto instead of Top (of course)

 

Also I needed to set table height to fixed, otherwise it would print just 2 records per page and pull the bottom text up to below the 2-record table instead of at the bottom of the page. I might be able to handle the text shift via a separate form, but I'm not sure why it printed just 2 records per page.  Any thoughts?

 

Sherm

 

On 3/21/2020 11:17 PM, sherman levine wrote:

Just tried it (not much to do here these days).

Gives me one record per page.

Sherm

 

On 3/21/2020 10:49 PM, Sherman Levine wrote:

Really? I’ll give that a try tomorrow. 

Thanks

Sherm

 



On Mar 21, 2020, at 22:35, Keith Canniff <kcanniff@...> wrote:



Sherrm

You should be able to define the entire page as a single form with a table control in the middle just like an online screen.

The table control has 7 columns in it.

If you have less than 9 records the remainder of the 9 rows will be blank and so any fields outside the table will print in the same location

If there are more than 9 items then Magic will automatically start a new page with table continuing from record 10-19 and so on.

Is that what you're looking for?

Keith


From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of sherman levine <sherman.levine@...>
Sent: Saturday, March 21, 2020 10:11:09 PM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: [magicu-l] Printing multiiple lines on a standardized form

 

This is a 9.4 question, but I suspect it's still relevant to newer releases.

I have a form (in this case a Bill of Lading) which includes a fixed
height table plus lots of fixed text above, to the right, and below the
table.

  In this case, the table consists of up to 9 line items, each of which
has 7 fields.

Now, I've handled this in the past by putting 63 virtuals on the form, 
populating them by scanning a table and doing a bunch of varsets (in
this case 7) for each of the 9 line items, then printing the page etc.

It works, but lacks grace and elegance.

An alternative approach is to use 9 RTF edit controls, and synthesize
one RTF string for each line item.  That actually works quite nicely. I
can mix font sizes and styles, but I'm limited to fixed-width fonts if I
want the columns to align. (For those who want to try this, its easiest
to build a test line as a RTF text control, export the Magic task, and
see what the Magic-acceptable RTF looks like, then copy and replace)

I was wondering if anybody had found a better solution.

Thanks

Sherm




 

 


Virus-free. www.avast.com



Re: Printing multiiple lines on a standardized form

sherman levine
 

Keith

Fix size table=Yes works perfectly, but ends up with a blank are where I need to put the section for totals (which need to follow the details, and only on the last page). 

Fix size table=No is funky - and I suspect the problem relates to the text controls which are alongside the table.
If I print with an 8" vertical form, the form actually expands vertically beyond 8" (with a blank area at the bottom).  Magic has always had a problem dealing with vertically expanding controls (in this case the table) next to other controls, and this is probably just another example.

Probably simplest for me to limit myself to fixed-width text and go the RTF route

Thanks for your help. 

Sherm

On 3/22/2020 8:45 AM, Keith Canniff wrote:

Sherm,

 

Try the following. From the Data Repository do a Ctrl+G on your table, tell it to generate a “Print” output. Not sure if 9.4 did this but XPA will generate an output with a table control in a form, but I’m sure you have a copy of XPA around you could do this with just to verify

 

I would then:

  • expand the form (Change to inches from Dialog Units, and make it 8.5 x 11… or the Dialog Unit equivalent)
  • expand the table size to the 9 rows you want
  • change the table control properties to “Fix size table = Yes”
  • Move the table on the form approximately where you want it before entering all the other fields around it
  • Change the output to Preview so you can see it on the screen
  • Run it

 

You should get the desired output… at least you do in XPA.

 

Note: There should only be one form and it should be a “Detail” area and Expand Form = No

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 5:34 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith,

 

Thanks. Got it working

 

Output form needed to be set to Auto instead of Top (of course)

 

Also I needed to set table height to fixed, otherwise it would print just 2 records per page and pull the bottom text up to below the 2-record table instead of at the bottom of the page. I might be able to handle the text shift via a separate form, but I'm not sure why it printed just 2 records per page.  Any thoughts?

 

Sherm

 

On 3/21/2020 11:17 PM, sherman levine wrote:

Just tried it (not much to do here these days).

Gives me one record per page.

Sherm

 

On 3/21/2020 10:49 PM, Sherman Levine wrote:

Really? I’ll give that a try tomorrow. 

Thanks

Sherm

 



On Mar 21, 2020, at 22:35, Keith Canniff <kcanniff@...> wrote:



Sherrm

You should be able to define the entire page as a single form with a table control in the middle just like an online screen.

The table control has 7 columns in it.

If you have less than 9 records the remainder of the 9 rows will be blank and so any fields outside the table will print in the same location

If there are more than 9 items then Magic will automatically start a new page with table continuing from record 10-19 and so on.

Is that what you're looking for?

Keith


From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of sherman levine <sherman.levine@...>
Sent: Saturday, March 21, 2020 10:11:09 PM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: [magicu-l] Printing multiiple lines on a standardized form

 

This is a 9.4 question, but I suspect it's still relevant to newer releases.

I have a form (in this case a Bill of Lading) which includes a fixed
height table plus lots of fixed text above, to the right, and below the
table.

  In this case, the table consists of up to 9 line items, each of which
has 7 fields.

Now, I've handled this in the past by putting 63 virtuals on the form, 
populating them by scanning a table and doing a bunch of varsets (in
this case 7) for each of the 9 line items, then printing the page etc.

It works, but lacks grace and elegance.

An alternative approach is to use 9 RTF edit controls, and synthesize
one RTF string for each line item.  That actually works quite nicely. I
can mix font sizes and styles, but I'm limited to fixed-width fonts if I
want the columns to align. (For those who want to try this, its easiest
to build a test line as a RTF text control, export the Magic task, and
see what the Magic-acceptable RTF looks like, then copy and replace)

I was wondering if anybody had found a better solution.

Thanks

Sherm




 

 


Virus-free. www.avast.com



Re: Printing multiiple lines on a standardized form

Keith Canniff
 

Sherm,

 

Try the following. From the Data Repository do a Ctrl+G on your table, tell it to generate a “Print” output. Not sure if 9.4 did this but XPA will generate an output with a table control in a form, but I’m sure you have a copy of XPA around you could do this with just to verify

 

I would then:

  • expand the form (Change to inches from Dialog Units, and make it 8.5 x 11… or the Dialog Unit equivalent)
  • expand the table size to the 9 rows you want
  • change the table control properties to “Fix size table = Yes”
  • Move the table on the form approximately where you want it before entering all the other fields around it
  • Change the output to Preview so you can see it on the screen
  • Run it

 

You should get the desired output… at least you do in XPA.

 

Note: There should only be one form and it should be a “Detail” area and Expand Form = No

 

Keith

 

From: main@magicu-l.groups.io <main@magicu-l.groups.io> On Behalf Of sherman levine
Sent: Sunday, March 22, 2020 5:34 AM
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Printing multiiple lines on a standardized form

 

Keith,

 

Thanks. Got it working

 

Output form needed to be set to Auto instead of Top (of course)

 

Also I needed to set table height to fixed, otherwise it would print just 2 records per page and pull the bottom text up to below the 2-record table instead of at the bottom of the page. I might be able to handle the text shift via a separate form, but I'm not sure why it printed just 2 records per page.  Any thoughts?

 

Sherm

 

On 3/21/2020 11:17 PM, sherman levine wrote:

Just tried it (not much to do here these days).

Gives me one record per page.

Sherm

 

On 3/21/2020 10:49 PM, Sherman Levine wrote:

Really? I’ll give that a try tomorrow. 

Thanks

Sherm

 



On Mar 21, 2020, at 22:35, Keith Canniff <kcanniff@...> wrote:



Sherrm

You should be able to define the entire page as a single form with a table control in the middle just like an online screen.

The table control has 7 columns in it.

If you have less than 9 records the remainder of the 9 rows will be blank and so any fields outside the table will print in the same location

If there are more than 9 items then Magic will automatically start a new page with table continuing from record 10-19 and so on.

Is that what you're looking for?

Keith


From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of sherman levine <sherman.levine@...>
Sent: Saturday, March 21, 2020 10:11:09 PM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: [magicu-l] Printing multiiple lines on a standardized form

 

This is a 9.4 question, but I suspect it's still relevant to newer releases.

I have a form (in this case a Bill of Lading) which includes a fixed
height table plus lots of fixed text above, to the right, and below the
table.

  In this case, the table consists of up to 9 line items, each of which
has 7 fields.

Now, I've handled this in the past by putting 63 virtuals on the form, 
populating them by scanning a table and doing a bunch of varsets (in
this case 7) for each of the 9 line items, then printing the page etc.

It works, but lacks grace and elegance.

An alternative approach is to use 9 RTF edit controls, and synthesize
one RTF string for each line item.  That actually works quite nicely. I
can mix font sizes and styles, but I'm limited to fixed-width fonts if I
want the columns to align. (For those who want to try this, its easiest
to build a test line as a RTF text control, export the Magic task, and
see what the Magic-acceptable RTF looks like, then copy and replace)

I was wondering if anybody had found a better solution.

Thanks

Sherm




 

 


Virus-free. www.avast.com

3701 - 3720 of 196034