where to find source of labelwizzard?

[Nifrabar]

Hi!
I like my users to give oportunity to define own labelsize. For that reason I will mimic the labelwizzard.
I found source (from xsource.zip) for creating new labels. But the otherway around: creating the label-itself (especially the size) could not be traced.

Any suggestion?

 

[Olaf Doschke]

Theres HOME()+"Tools\AddLabel\labels.dbf" for the sizes. But perhaps even more important labels.reg registers sizes in the registry to show up in the wizard dialog. This is only done once for the first time usage. So it has to be somewhere in the source code, where the labels.reg file is referenced.

Bye, Olaf.

 

[Olaf Doschke]

Tools\xsource\VFPSource\addlabel
The newlabel form is a dialog to define new label sizes.

In my versin of xsource there is an error in the file references of that project. registry.vcx is assumed relative to addlabel.pjx in ..\wzcommon\registry.vcx, while it's in ..\Wizards\wzcommon\registry.vcx
You can fix that with the foxpro dialogs for finding the missing components, when you open the project and the two forms.

And then you have a form to define a new label sheet as newlabel.scx

Bye, Olaf.

 

[Koen Piller]

Hi,

There is a addlabel.app in your home()\Tools\Addlabel directory. You may use this app to do that job.

Groet,

Jockey(2)

 

[Nifrabar]

In table 'labels.dbf' the memofield data contains all values required to create a label with certain size.
For reports I use to hack the 'FRX' to tailor the report according users'wishes (e.g. set a left or topmargin).
Same I like to do with the lbx to enable (by my users) change number of columns on a sheet, height and width etc. For that I like to trace the labelwizzard to find out how the data from the label.dbf is set into the several fields of the lbx.

But up to now I can't find that wizard. Any idea?
@Olaf : the addlabel project just creates data of a new-designed label and stores that data into the label.dbf. I am looking for the proces the otherway around, pulling data from the label.dbf and set that into a lbl.

-Bart

 

[Nifrabar]

well OK I found it in the reportengine!

-Bart

 

[Olaf Doschke]

The reportengine is rendering reports, not generating labels. You are really asking for CREATE LABEL?

Bye, Olaf.

 

[Nifrabar]

Olaf, In normal I always use reports as label. But for the sake that my users want to create own label-size I am figuring out how to retrieve data from the label.dbf and set sizes of labels accordingly. As labels and reports are very similar I will thereafter do same to get reports as labels (as usual for me).
I disagree that the reportengine just renders reports. Also labels are created once you use as 2nd parm "LABEL" in report.prg.

-Bart

 

[Olaf Doschke]

OK, let's do a little defining terms here

report.prg, if you see this as the "report engine", then you're totally on the wrong track, and such differences are leading to misunderstandings, leading to not getting the answers you need.

OK, starting:

1. report.prg is a prg inside xsource\wizards and the header comment says, what it is:

* STUB for the Report Wizard

* This is the stub which you should copy (place the modified version in
* your Wizard's directory), rename, and modify to call your wizard.

2. Report engine
Is what you can set to mode 80 (legacy, fxp based) and 90 (modern, also fxp based, with or without reportlistener support). The report engine still is native core of vfp9.exe or vfp9r.dll, reportlisteners are a class extending the engine, I would agree if you would count theses classes to the engine. In 90 mode the reportengine uses the reportxyz.app files, which are reportoutput.app, reportpreview.app and reportbuilder.app, so you may count creating reports to the engine, I still don't do that. These apps are not the engine, they are used by the engine in 90 mode, the 90 is pretty much a hull of functionalities, but still it's CREATE REPORT or CREATE LABEL, which trigger usage of the reportbuilder.app and not vice versa.

I can agree the engine does more than just rendering the report, but actually the creation of reports is quite seperate and has not changed much, it still creates frx,ldb files, you can just protect parts of a report. So I agree I was also wrong. Nevertheless if the report engine is mentioned in the vfp help, it talks mainyl about rendering reports, including the support of report listeners. Likewise the sql engine mainly is referred to about executing SQL-Selects,Updaes, Deletes, but not creating or altering tables.

3. Report System
The report apps are part of the report system, that's more general than just the engine.

OK, now.

And now let's look what report.prg does. If you set p2 = "LABEL", it sets m.cWizardToRun = "LabelWizard" and then continues to do

* Modify here to reference your wizard's .vcx.

set classlib to RptWiz

public oWizard

* The name "oWizard" is used in automated testing and should *NOT* be changed.
oWizard = createobj(m.cWizardToRun,...

So it's calling the Labelwizard class of RptWiz.vcx, that's what you are looking for.

But initially you said you'd like to give your users the opportunity to define own labelsizes. It's obvious they would then also need to be able to create labels on the new label sizes, but that's still merely CREATE LABEL, which is going through a label size choice dialog for me.

Bye, Olaf.

 

[Nifrabar]

Hi Olaf,

Again I'm impressed about your deep knowledge of all details!
For me this requires time to figure out all the code supplied with the wizards.
On my wishlist there's the possibility to have my users full control about sizes but also about the content of the labels.
Currently in my app for labels it's all pre-coded and it would be a step forward if they could select own size.
2nd subject than is to provide them with further control about the content of the label.
Taken the above into account I'm just figuring out how to set all pulled data from label.dbf into the LBL.
Anyway thanks again for pointing me to the right ways to follow.

-Bart

 

[Olaf Doschke]

CREATE LABEL does pull it's list from the label.dbf, too, I think, but I may be wrong there. It may also only read the registry entries I mentioned earlier and then it would be important this is in synch with labels.dbf. At least there is a double source of data, as the default label records are written to the regsitry via labels.reg. Well, labels.reg does not read from lables.dbf, it merely has the same infos in itself, but maybe that's also imnportant, when it comes to a discrepancy in the list of labels you can pick from.

I never used this before, I merely read the code. I also learn whilke going through this. I may have found out earlier, if you would have described your needs in another way. Not so important.

Bye, Olaf.