Resize.vcx error 1st time through then goes away

[gairo50]

Trying to use the Resize.vcx to maintain form when resizing.. Getting error first time I use then goes away.

Hi I followed a thread on this forum to a Resize.vcx library so I can resize my screen while maintaining form object/font proportions.

I added this code to the INIT of my form
This.NewObject( 'Resizer', 'stdResizer', 'tools\akins.vcx' )

Added this to the resize method of the form.
This.Resizer.AdjustControls()


The first time my form is called I'm getting an error Program: "Resizer.Saveoriginaldimensions" "Data type mismatch" on about 10 of the objects
on my screen. The other 200 hundred+ objects give no error and after ignoring the error about fifteen times the screen appears and I
can resize it and all works.

2nd time I call my program from the command prompt (without exiting VFP just quiting my program) the form and my program load with no errors and the form resizes correctly. If I go to the command prompt and type: "RELEASE ALL" and try to run my program again I get the errors.

Is anyone familiuar with the Resizer.vcx or know what I might look for?


Thanks

 

[Mike Lewis]

Hi Gairo,

What exactly is Resizer.vcx? Is it a proprietary class, or a bit of freeware? Or something you wrote yourself?

If you obtained it from a third-party, you might try contacting that person for advice.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[gairo50]

Hi Mike,

Got if off this site.. It was recommended in several threads so I tried it on a form. Seems to work fine the 2nd time around from the command prompt.. but 1st call to my form the Resize.vcx seems to not be able to get the original dimensions of about 10 objects on the form. If I restart the app the 2nd time the error goes away as if the data time is now in the correct format. I figured someone more familuar with this vcx might know how to tame the thing.

I haven't posted up here for a couple of years but I'm still coding in VFP are there a lot of members still active in VFP up here?

Thanks,

Gary

 

[Mike Lewis]

Gary,

I don't know where on Tek Tips you downloaded it from. There's no download area here, and I can't see it in the FAQ section.

But, with luck, someone here will recognise it and will be able to help you. Failing that, maybe the author's contact details are somewhere in the source code.

Regarding the number of active VFP members here, as you probably know there are fewer developers using VFP than there were a few years ago. Most VFP-related forums are less active nowadays. But this one is still quite busy, with a hard core of active members. We do manage to answer most questions reasonably quickly.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[gairo50]

Hi Mike,

Don't think I downloaded it here just got a link to it from here or maybe Foxite.com. Not sure if there is a good Resize utility for VFP that accurately resizes the from when the user manually sizes it.

If anyone knows of a good resize utility for a VFP from please adivse.

Thanks,

Gary

 

[Mike Lewis]

Gary,

In fact, resize utilities are obsolete now, because VFP allows you to anchor your controls to one or more edges of the form (or other container). This means that you can have the controls move or resize automatically when the user resizes the form (I assume that's what resizer.vcx does).

If you are not familiar with this, read the Help topic on the Anchor property. (But note that this feature is only available in VFP 9.0 and above.)

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[gairo50]

Hi Mike,

I will read.. but my product runs in vfp 6,7,8 and 9 and I even have a few vfp 5 clients.. Yea I know hard to believe but it's true for some unknown reason.

Thank you for the input,


Gary

 

[Mike Lewis]

That doesn't sound like a very good setup.

Assuming you have just one product, it means you must either keep separate versions of the application for each VFP version (which would be a maintenance nigntmare), or you must write the app in the lowest common denominator (VFP 5), and forego the vast improvements to VFP since that version.

A much better approach would be to always use the latest version for your development, and to make sure that all your customers have the runtime files for that version. After all, it doesn't matter to them whether they are running under VFP 5 or VFP 9 - they won't even know about it.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

In fact you should know where you downloaded it from, tht'd be a good basis for help.

I remember having helped someone using that. As far as I remember you drag&drop that on a form, not create an object in form.init, that's too late in the instanciation time. Remember form init comes after the init of all form controls and other subobjects put on the form.

The resizer class should also be put on the form to instanciate first. Then there also was one line of code to add. It's all in the readme of that class. You shoudl read readmes...

Bye, Olaf.

 

[Olaf Doschke]

I found a reference here:

http://www.tek-tips.com/viewthread.cfm?qid=1426615

The class I mean is call MWresize, though. Marcia Akins code might also work out for you, but works the way you describe it. Nevertheless, it's meant to be added to a base form you inherit from, which might be essential for it to work.

Bye, Olaf.

 

[gairo50]

Thank for all your help.

I tried four VCX tools for resizing the screen.

ONLY 1 lived up to the job ... Keeping ALL fields intacked and aligned properly as I resized.

MWRESIZE41.ZIP

Downloaded here:

http://www.dfpug.de/Forum/catbody.afp?!_3LO18Y2G4&nsec=10&cname=MWRESIZE41.ZIP

Thanks again,

Gary

 

[Mike Lewis]

Gary,

Glad to see you've found a solution. However, I'd still like to know how you manage to support the same application under six different versions of VFP. Do you have six versions of your code? Or do you take care only to use features available in VFP 5.0?

I'm asking this partly out of curiosity, and partly because I suspect there might be some misunderstanding about your reasons for doing this.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[gairo50]

Hi Mike,

Well I've managed to create a product (MAXShipper UPS,FedEx,USPS,LTL Shipping Manifest System Certifed by UPS/FedEX/USPS) that integrates with many accounting systems some are VFP based.. Since the conception I created a COM API that can integrate with many languages. All using VFP and all compatible with VFP 6,7,8,9 code. The API I compile in VFP 7 (middle ground). I don't use features that are explicate to VFP 9. For VFP 5 which I only have a few clients that have heavily modified accounting systems and they pay dearly for there upgrades. So there is 1 build in VFP 7 that I create the API with.. This COM object is compatible with ALL MS Languages and runs in 32/64 bit. I integrate with MS Dynamics, Sage Acpacc ERP, Peachtee, Pro Series, MAS 90/200, Accountmate, TIW ALERE, Qickbooks, and a few online stores Amazon, Volusions using XML posts etc.. My product new website under construction:

http://www.MAXShipper.com

have old we site but not as nice.

So there is a free plug for me a bit of information for you. I've managed to create a VFP app that has lasted me 25 years and I think I can make it work another 10 before it's a done product.

Thank you for the help... I'll be back

Gary

 

[Mike Lewis]

So, if I've got this right, you develop in VFP 7.0, but your customers might have runtimes for other versions. If that's the case, I would have thought there were big advantages in moving everyone to the same set of runtimes. It wouldn't be particularly difficult, and there'd be no cost associated with it. You'd then be able to move your development environment to VFP 9.0, which would give you a substantial number of benefits compared to 7.0.

On the other hand, I can see that, if you're happy doing things the way you are, you might feel there's no compelling reason to change. But I think you should at least consider the possibility.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Indeed the runtimes of VFP are so small, that you can add them to whatever runtime used for the main product, be it a VFP runtime or anything else. The benefit from the perspective of runtime installations is small, the benefit for the programming of a COM interface may exist.

If that COM interface you provide mainly is a data access interface I can understand you stay with VFP7, but your COM interaface seems to include Forms, if you need a resizer component. So you would benefit from VFP9 in some better support for Aero style and minor other GUI advances besides productivity advances of the VFP IDE itself. At least VFP7 already has Intellisense, the READWRITE clause, introduced some XML functionality and some other very important benefits. VFP8 braught structured error handling, the Cursoradapter and XMLAdapter and VFP9 brought a new report engine and many SQL enhancements in terms of subselects. While the last benefit is not as much discussed as the report engine, it's perhaps even more beneficial for your product. IIRC VFP7 has made the most bloat in CDXes and VFP9 has the best Fox SQL engine.

Bye, Olaf.

 

[gairo50]

Hi Oalf,

I have several models in my design..

1. Run Inside a VFP accounting system like AccountMate, TIW Alere, Sage Pro Series which are written in VFP. So whatever version of VFP the client calls my product from it runs. Using a DO XXXXXXXX command. Example: Client is running Sage PRO (Old name SBT) My product runs inside of ALL version of Sage PRO/SBT from 25 years back to the current build just released. So I can sell to old Sage/SBT customers and new clients and run from inside there product with 100% compatibility with the version of VFP they are running 5,6,7,8,9. So that's big advantage to keeping the code generic I can sell to a MUCH larger market $$$$$.

2. I then have the COM API which is basically a wrapper to call my app from ANY MS compatible application. The COM API could be complied in several flavors of VFP 7,8,9 (VFP 6 can't hang with the functions inside the API) really it's just a front-end to my system. With this configuration my API interface runs INSIDE of MAS 90/200, Accpac ERP, MS Dynamics and many custom applications.

So because my product runs INSIDE many native VFP applications I need to keep the code semi generic.. There are switches inside the code for version checks to ensure compatibility. But I try to keep things compatible with 6,7,8,9.

It works from a marketing stand point.. Doesn't allow for the latest and greatest code but you can do allot with old VFP if you have a great support team. ie.. All the great developers that have helped me over the past 25 years by creating EXCELLENT 3rd party add-ons to VFP. Could not have done it without them. I'm just a mediocre programmer but when I really needed stuff that was beyond my skill set these guys from ALL parts of the glob have come through for me and all of my customers.

Thank you VFP community

Gary

http://www.MAXShipper.com