Printable View
I have previously used a multipage Userform from Office in VB 6. VB treats it as a Designer.
Today, I encountered something strange.
In VB 6, for a particular multipage Userform, only the caption bar is displayed.
I can use the maximize button, or drag, to change the size.
This seems rather odd.
Is there a property I need to set to cause the Designer to open full size?
Hi Howard
I can understand why you might import a userform into VB6 but it isn't recommended. VBA userforms use a totally different set of controls to VB6, those controls are provided in the FM20.dll which is not redistributable. All vba controls are lightweight controls that are windowless, check here for more info http://support.microsoft.com/default...b;EN-US;224305
VB6 will refer to it as a designer because it is a class it doesn't know about, in fact a vb6 form is also a designer purely used to give you a graphical design time interface, look at any vb6 .frm file in a text editor and you'll see each control and it's placement. If you use any controls in your vb6 form that store binary data such as picturebox controls you will also get a file with the suffix .frx, this is the file that stores the binary data for the form.
If you export even the most basic vba userform, it will have a corresponding .frx file as all the objects are oleobjects and are stored in this file. I suspect you may be missing your .frx file from the folder where you have stored your .frm file. Try looking for the frx file.
I would recommend rebuilding the form in vb6 though.
HTH
Thanx, I knew all that.
11 of the 14 Userforms in the project have already been converted to Forms, the other 3 will be done eventually.
I was asking about a fix for a particular problem.
There is no property to adjust with a userform in VB6 because they are unsupported, as per the note in the web page I referenced:
NOTE: The use of these Microsoft Forms components in your own compiled applications, such as those written with Microsoft Visual C++ and Microsoft Visual Basic, is not recommended or supported. These controls were designed and tested to work exclusively within Microsoft Office and its Visual Basic for Applications environment.
The best you can try, short of rebuilding the form in VB6, is exporting the file and trying again. I suspect the issue is with a particular control. Did you check for the existence of the correct frx file?
I found the cause of the problem.Quote:
Originally Posted by Howard Kaikow
The Initialize event of the Userform includes the following statement:
Me.Height = 335
Commenting out that statement allows the Designer to display full size (not what I want).
Well, I've already converted the other 13 Designers to VB Forms, so I will soon tackle this last one, by far the most complex, as it is multipage. I'll first check whether SSTab control will do the deed.
Result! Well done Howard, perseverance pays off :)
Enjoy SSTab ;)
I guess this was always obvious, but I'll state it anyway.
The ultimate cause of the problem I raised in this thread was caused merely because when importing a Userform as a Designer, VB does does not bother to convert hard-coded height/width values, even when it knows that the value is needed as in
Me.Height = 335
So I have to go thru the Form and attempt to figure out correct values. Very tedious, but doable.
Of course, after spending most the past 7 daze converting 14 Designers to Forms, I'm not sure my brain cells can deal with this now.
And then, I move on to determining what code was broken by the conversion to Forms. For example, some vbModal Forms present a problem if I am running from source in VB whilst Word is running the DLL, but the code appears to work fine if Word is running from a compiled DLL. The former is needed so I can debug.
Howard
For completeness of this thread as this is probably a little late now, VB doesn't ignore the height property, nor the width property, it uses a different scale to vba.
VBA uses 'Points' to measure height and width, position etc, a point is 1/72nd of an inch. VB uses TWIPS which is 1/1440th.
A reasonable conversion is to multiply by 20 (1440/72 = 20).
VB was ignoring the values only in the sense that it did not convert the values where the use was to assign to a height/width property.Quote:
Originally Posted by zilpher
Yes, I used 20 for just that reason, but it's not exact due to snapping to grid points. Alas, the SSTab control, does not display grid points, so the task was a big harder.
Since importing a Userform into VB is not officially supported, I have no right to complain, but being a charter member of the CS (Curmudgeon Society), I'll do so anyway.
In practice, I can understand why a compiler would just take the value for each expression and assign to the target variable without considering how the value is used.
But, and I do have a big butt!
Word does take different units into account when importing a WordBasic macro into VBA, at least as far as the Dialog statements. I might even have a WB version of this stuff hanging around. If so, I'll take a peek at what Word did when importing into VBA. Although, the WB version did not have the complex/multipage dialogs, so the equivalent problem may not have existed, for me, moving from WB to VBA.
To move folkes from VBA to a .NET-ized VBA, the conversions will need to do the right thing.
With a bit of luck, if/when vba gets .Net'd it'll fall into line with the rest of Visual Studio and use Pixels, they did that with VB6 -> vb.Net, the TWIP is no more...
The important thing is for Office to move to windoze forms so we no longer have to deal with different form engines,
Yes I agree, that's certainly one of the important changes to be made, and given the .Net Framework I think it's inevitable, but I'm not holding my breath as I'm not convinced there'll be a vba.Net. I look forward to dropping TWIPs not just from a form point of view but anything graphical. I work mostly in .Net now, so moving back and forth twixt the two is a strain for my brain.
I wonder what the .Net conversion of office will bring if it ever comes. It moves code much further away from the ethos of Office development and beyond many companies investment in vba technologies.
This presents Microsoft with a heck of a dilemma, Office is the big money spinner for MS, millions of vba developers out there writing mission critical software on a technology that is already out of date. It's ok to expect a programmer to get training and keep up, but if you're a financial analyst whose job description does not include writing code but loves doing it and saves thousands a year doing it, how are you going to convince your boss you should go on a .Net course? I have first hand experience of this (not moving to .Net but vb6, asp and c++), I had to battle with my bosses to be allowed to develop code and was lucky to intercept a quote from a partner company for ?300k that I managed to deliver in one week (no brainer for an IT Director). Before I took a job as a developer I was a Project Manager, I used to have to sneak onto the likes of Excel-L, VISBAS-L and MrExcel when no one
was looking, I suspect this is still the case for many people. VBA has become a rod for Microsofts own back.
I wonder if vba will just evolve in it's current form and not move to .Net as you can easily create Office solutions in vb.Net or C# using Office 2003 and Visual Studio.Net 2003, leaving VBA alone allows non .Net developers to carry on using vba. Maybe there'll be vba and vba.net implemented side by side. MS will have to address it at some point, Longhorn continues support for COM and OLE but it
doen't extend them, and the official line is they are 'done' technologies.
Maybe .Net will skip Office in it's current form and wait for a new type of Office application that isn't an eclectic mish mash of applications masquerading as a suite, but a single application that incorporates all the functionality an Office user would ever use. The official line from MS is that they will support vba after integrating .Net into office, even though they don't know how they're going to do that.
I seem to remember reading somewhere that vba would still be around for two full product cycles of Office from XP, so that's one down, one to go... one things for sure, vba will be around for longer than that because if they break it, people just won't move. My old company (7000 desktops) upgraded their Office suite last year, from Office 95.
Yes, indeed and that's why MSFT propably will hold back the replacement of VBA in Office for a longer period.Quote:
I wonder what the .Net conversion of office will bring if it ever comes. It moves code much further away from the ethos of Office development and beyond many companies investment in vba technologies.
MSFT is pushing for VSTO a lot and I wouldn't be surpriced if MSFT will port future development from Office to the NET-platform instead.
After all, the Office-suite is an end-user enviroment.
Kind regards,
Dennis
VSTO indicates the direction, i.e., allowing Office code in ANY of the .NET languages.Quote:
Originally Posted by XL-Dennis
The big hole in VSTO Is that you cannot use global Word templates and macros cannot be ported in templates in .NET Code.
VBA is not an end user froendly "macro" language, but neither was WordBasic.
My biggest objection to .NET is that there's no way to get the level of code security afforded by compiling VBA into a VB 6 DLL or EXE.
I expect that MSFT will support VBA for at least as long as they have supported WordBasic, bit at some point, the object models wil only get updated for the .NET languages.
Yeh, I think VSTO is a view of whats to come, I can see vba staying as it is and ultimately being replaced by a .Net type environment soultion, maybe as user-friendly as vba, maybe not.
I agree, Office is an end user environment but then they stuck vba on the end of it and made it a development tool too. I think many vba developers do it as a secondary function to their jobs, I used to have to code in secret at my last place. I think MS will continue support for vba for a long time yet, and move new development to a .Net type of environment much like the change from dialogs to userforms in the past, albeit on a different scale. Whatever they choose to do, I look forward to it, there could be a fair chunk of freelance work coming out of it :)
I'll speaketh only about Word, as I paid no attention to macros in the other products prior to VBA.Quote:
Originally Posted by zilpher
Word has NEVER had a real macro programming language. A real macro language woulsbe something like the language useds in say, GPSS ( a simulation language).
Oh well, not much point in guessing, MSFT will do what MSFT will do (how's that for an accurate forcast?).
Any organization with any sense will either have employees properly trained to use VBA, etc, or will hire folkes like me who know how to DESIGN, DOCUMENT (a word disappearing from many dictionaries), and PROGRAM (not just hack).
I do recall that when I first started using WordBasic in November 1993, I was so frustrated that I ran to a local bookstore om a Sunday (about 15 minutes before the store closed), and purchased the first edition of Woody Leonard's Hacker's Guide. At the time, it was the best purchase I had ever made:
1. It included a tip that explicitly told me how to do what I needed to do. Note that the next version of Word included that tip in the built-in Help.
2. Perhaps, most interesting was about 20 pages in which Woody Leonard described his frustation when he first started using Word Basic. It was almost exactly the same experience I was was having, so if misery loves company, that sure made this miserable cumudgeon a lot happier! Hmmm, can a curmudgeon ever be happy/happier?
Funny you should say documentation is a word disappearing from dictionaries, I find that design is the bit missing in most apps I come across, what the app wil do is documented, but there's no initial design, usually because the documentation was written after the app went live :D tsk tsk
I've worked in four large organisations that have cottage industries of users developing code in office applications as an adjunct to their day job. It's frowned upon by the IT department but encouraged by the business because "I.T. take so long to deliver and I need it now". It's an engrained culture thing, and a great way of leaving a company only to return on an inflated day rate to support the code stuffed into a spreadsheet by a user.
There are many many untrained, unofficial vba developers out there hence I think, the need to support vba going forward. It's good to see training being written here at VBAX, it's about time some certification was available.
A happy curmudgeon Howard? Pah! That reminds me of a conversation I had with our standards guy once, he'd picked me up on a misplaced apostrophe in a design document (doing himself no favours I might add). "You're a terrible pedant" I said to him; "On the contary" came his immediate reply, "I'm an excellent pedant". Touch
Clear as mud :DQuote:
Oh well, not much point in guessing, MSFT will do what MSFT will do (how's that for an accurate forcast?).
I agree that the general trend is to jump over important aspects of developing and maintance. It seems to be the standard of owned developed solutions & application within companies.Quote:
Any organization with any sense will either have employees properly trained to use VBA, etc, or will hire folkes like me who know how to DESIGN, DOCUMENT (a word disappearing from many dictionaries), and PROGRAM (not just hack).
Recently I was asked to look through an application developed by the customer themselves. When I asked my first question about documentation the staff looked at me as I was from outer space...
My experience tells me that too. Employees develop solutions to solve their problems and all of the sudden the solutions turn over to be important by the companies and when things going in the wrong direction they call for external help. Too many times I have been forced to completely rebuild solutions due to this scenario.Quote:
There are many many untrained, unofficial vba developers out there hence I think.
One reason for its existence is that is very easy to access VBA and get something done via the macro-recorder etc.
Yes, VBAX approach with certifications is a good way and I welcome any kind of developing towards a better standard, including documentation as well as comments in code :yes
Kind regards,
Dennis