Creating form from code

[Domac]

Hi ,

I am creating form from code using 'CreateForm' and 'CreateControl'
functions.
Everything works fine, as we plan to deploy MDE version soon, question is
will it work in MDE enviroment??


Thanks a lot.
Domac

 

[Allen Browne]

No. CreateForm won't work in an MDE.

 

[Domac]

Where to find list of MDE limitatons?

Thanks,
Domagoj

 

[Domac]

Is there any way to create form and controls, wich is compatible with MDE?

 

[Douglas J. Steele]

There are some details at
http://msdn2.microsoft.com/en-us/library/aa189988(office.10).aspx (don't
work if you're not using Access 2002: that article applies to all versions)

 

[Douglas J. Steele]

To be honest, it's very unusual to be creating forms and controls
programmatically in an application.

Why not explain why you feel it's necessary, and perhaps someone can suggest
an alternative?

 

[David W. Fenton]

Where to find list of MDE limitatons?

Well, if you'd bother to read the help file on what an MDE is, you
should have understood already *why* you can't create forms in an
MDE. Most of the "limitations" of an MDE flow directly from what an
MDE *is*, which is an Access project with the canonical code
stripped and only the compiled code left. This means that the Access
project is read-only throughout.

And all of that should be obvious from the definition of what an MDE
is. At least, for anyone who takes the time to think about it.

 

[Domac]

Here is situation :


Something about applivation : Application is developed for purpose of
manufacture menagment.
We are currently designing a module for check-list functionality, wich
consists of serie of properties and each of them is different data-type and
has different type of entry.
In practise , it looks like this:


PropertyName PropertyDataType
PropertyControl
WIDTH NUMBER TEXTBOX
HEIGHT NUMBER TEXTBOX
LENGHT NUMBER TEXTBOX
CHIPBOARD_DECOR TEXT COMBOBOX
CHIPBOARD_THICKNES NUMBER COMBOBOX

In real situation we have from 30 to 100 properties per product.
Idea is to enable design department to define properies and list of values
(for combobox properties) for each of product entity.
Different set of key properties is for wardrobe, table , laboratory table,
office closet.
So when sales personal create demand towards manufacturing department, they
must fill check-list to define each of key properties for product entity.
What is my problem?
I have to dynamically define a form depending on product entity user
selected, and i have achive it , but it must be compatible with MDE
deployment.
My solution is based on 'CreateForm' and 'CreateControl' functions, works
great ,each time i generate frmSubForm and display it throught SubForm
control.
Back few years, when I developed in VB6 i had comfort to dinamically create
controls from code using load function (if my memory works), in access i can
achive it only in design view using 'CreateControl' function.
Is there alternative ?
I have another idea, but I would like to avoide playing with visible
property.







Here is my code:

<CODE START>
On Error Resume Next


SubStavke.SourceObject = "frmProdajaPLIzradaSubPrazno"
DoCmd.DeleteObject acForm, "frmProdajaPLIzradaSub"


Dim frmTmp As Form

'Podesi svojstva forme u ovoj fazi
Set frmTmp = CreateForm

frmTmp.Section(acDetail).BackColor = Me.Section(acDetail).BackColor


Dim rstGrupe As DAO.Recordset


Dim ctlLabels() As Label
Dim ctlCombos() As ComboBox
Dim ctlTexts() As TextBox
Dim ctlLines() As Line

Dim lngLabelsCount As Long
Dim lngCombosCount As Long
Dim lngTextsCount As Long
Dim lngLinesCount As Long

Dim lngRazmak As Long 'Izmeðu kontrola!
Dim lngVertikalnoStanje As Long

Dim lngGrupeXOffset As Long
Dim lngSvojstvaXOffset As Long
Dim lngSvojstvaNazivWidth As Long



'Postavi uvlaku po x-u
lngGrupeXOffset = 500
lngSvojstvaXOffset = 500

'Postavi dimenzije
lngSvojstvaNazivWidth = 2500




'Vertikalni razmak izmeðu kontrola!
lngRazmak = 100




Dim strSvojstvaGrupe As String

strSvojstvaGrupe = "SELECT ProdajaPLSvojstvaGrupe_INT.SGrupaRb,
ProdajaPLSvojstvaGrupe_INT.SGrupaNaziv ,SGrupaId " & _
"FROM ProdajaPLSvojstvaGrupe_INT " & _
"GROUP BY ProdajaPLSvojstvaGrupe_INT.SGrupaRb,
ProdajaPLSvojstvaGrupe_INT.SGrupaNaziv,SGrupaId " & _
"ORDER BY ProdajaPLSvojstvaGrupe_INT.SGrupaRb;"


Set rstGrupe = CurrentDb.OpenRecordset(strSvojstvaGrupe, dbOpenSnapshot)

'Odma n a prvu grupu u listi
rstGrupe.MoveFirst


'Sve kreiraj pod generiranim imenom tipa "From1"


While Not rstGrupe.EOF = True

ReDim Preserve ctlLabels(lngLabelsCount)
ReDim Preserve ctlLines(lngLinesCount)
'Kreiraj kapcije za grupe svojstava
Set ctlLabels(lngLabelsCount) = CreateControl(frmTmp.Name, acLabel,
acDetail, , , lngGrupeXOffset, lngVertikalnoStanje, 1000, 300)
Set ctlLines(lngLinesCount) = CreateControl(frmTmp.Name, acLine,
acDetail, , , lngGrupeXOffset, lngVertikalnoStanje, 1000, 300)

'Svojstva labela!
ctlLabels(lngLabelsCount).Caption = rstGrupe!SGrupaNaziv
ctlLabels(lngLabelsCount).FontName = "Arial CE"
ctlLabels(lngLabelsCount).FontSize = 9
ctlLabels(lngLabelsCount).ForeColor = 16776960
ctlLabels(lngLabelsCount).FontBold = 800
ctlLabels(lngLabelsCount).SizeToFit
'Linija
ctlLines(lngLinesCount).Top = ctlLabels(lngLabelsCount).Top +
ctlLabels(lngLabelsCount).Height
ctlLines(lngLinesCount).Left = ctlLabels(lngLabelsCount).Left
ctlLines(lngLinesCount).Width = 5000
ctlLines(lngLinesCount).Height = 0
ctlLines(lngLinesCount).SpecialEffect = 2
'Pomakni brojaèe!
lngVertikalnoStanje = lngVertikalnoStanje + lngRazmak +
ctlLabels(lngLabelsCount).Height
lngLabelsCount = lngLabelsCount + 1
lngLinesCount = lngLinesCount + 1
'Pobroji svojstva za grupu sortirano po rb unosa!
Dim strSvojstvaZaGrupu As String
Dim rstSvojstvaZaGrupu As DAO.Recordset

strSvojstvaZaGrupu = "SELECT * FROM ProdajaPLSvojstva_INT WHERE
SvojstvoGrupaId=" & rstGrupe!SGrupaId & " ORDER BY SvojstvoRb"
Set rstSvojstvaZaGrupu = CurrentDb.OpenRecordset(strSvojstvaZaGrupu,
dbOpenSnapshot)

'Træi na prvi!
rstSvojstvaZaGrupu.MoveFirst

While Not rstSvojstvaZaGrupu.EOF = True
'NASLOVI SVOJSTAVA
'Prvo label zatim kontrola za unos!
ReDim Preserve ctlLabels(lngLabelsCount)

'Kreiraj kapcije za grupe svojstava
Set ctlLabels(lngLabelsCount) =
CreateControl(frmTmp.Name, acLabel, acDetail, , , lngSvojstvaXOffset,
lngVertikalnoStanje, lngSvojstvaNazivWidth, 300)

'Svojstva labela!
ctlLabels(lngLabelsCount).Caption =
rstSvojstvaZaGrupu!SvojstvoNaziv & " :"
ctlLabels(lngLabelsCount).FontName = "Arial CE"
ctlLabels(lngLabelsCount).FontSize = 9
ctlLabels(lngLabelsCount).ForeColor = RGB(255,
255, 255)
ctlLabels(lngLabelsCount).FontBold = 400
'ctlLabels(lngLabelsCount).SizeToFit
ctlLabels(lngLabelsCount).TextAlign = 3 'Right

'Pomakni brojaèe!
lngLabelsCount = lngLabelsCount + 1


'Kontrole za unos Select case
Select Case
(rstSvojstvaZaGrupu!SvojstvoUnosVrsta)

Case "UNOS"
'Textboxovi!
ReDim Preserve ctlTexts(lngTextsCount)

Set ctlTexts(lngTextsCount) =
CreateControl(frmTmp.Name, acTextBox, acDetail, , , lngSvojstvaXOffset,
lngVertikalnoStanje, 1500, 300)
ctlTexts(lngTextsCount).Left =
ctlLabels(lngLabelsCount - 1).Left + ctlLabels(lngLabelsCount - 1).Width +
50
ctlTexts(lngTextsCount).Width = 1500
ctlTexts(lngTextsCount).FontName =
"Courier New CE"
ctlTexts(lngTextsCount).FontSize = 9
ctlTexts(lngTextsCount).Name =
rstSvojstvaZaGrupu!SvojstvoNaziv

Select Case
(rstSvojstvaZaGrupu!SvojstvoTip)
Case "BROJ"
ctlTexts(lngTextsCount).DefaultValue
= 0
ctlTexts(lngTextsCount).Format =
"Standard"

Case "TEKST"
ctlTexts(lngTextsCount).DefaultValue
= ""
ctlTexts(lngTextsCount).Format =
""

End Select


lngTextsCount = lngTextsCount + 1

Case "LISTA"

'Textboxovi!
ReDim Preserve ctlCombos(lngCombosCount)

Set ctlCombos(lngCombosCount) =
CreateControl(frmTmp.Name, acComboBox, acDetail, , , lngSvojstvaXOffset,
lngVertikalnoStanje, 2000, 300)
ctlCombos(lngCombosCount).Left =
ctlLabels(lngLabelsCount - 1).Left + ctlLabels(lngLabelsCount - 1).Width +
50
ctlCombos(lngCombosCount).Width = 2000
ctlCombos(lngCombosCount).FontName =
"Courier New CE"
ctlCombos(lngCombosCount).FontSize = 9
ctlCombos(lngCombosCount).Name =
rstSvojstvaZaGrupu!SvojstvoNaziv
ctlCombos(lngCombosCount).RowSourceType
= "Table/Query"
ctlCombos(lngCombosCount).RowSource =
"SELECT Vrijednost FROM ProdajaPLSvojstvaListe_INT " & _
"WHERE
SvojstvoId=" & rstSvojstvaZaGrupu!SvojstvoId & " " & _
"ORDER
BY ItemId"

ctlCombos(lngCombosCount).LimitToList =
True



lngCombosCount = lngCombosCount + 1


End Select



'---------------------------------------------------------------------------------------------------------
lngVertikalnoStanje = lngVertikalnoStanje + lngRazmak +
ctlLabels(lngLabelsCount - 1).Height
rstSvojstvaZaGrupu.MoveNext

Wend

'----------------------------------------------------------------------

rstGrupe.MoveNext


Wend
'Finalne korekcije!

frmTmp.Section(acDetail).Height = frmTmp.Section(acDetail).Height + 200
frmTmp.DividingLines = False
frmTmp.NavigationButtons = False
frmTmp.RecordSelectors = False
frmTmp.ScrollBars = 2


Dim strFrmTmpName As String

strFrmTmpName = frmTmp.Name

DoCmd.Save acForm, frmTmp.Name
DoCmd.Close acForm, frmTmp.Name, acSaveYes
DoCmd.Rename "frmProdajaPLIzradaSub", acForm, strFrmTmpName


<CODE END>

 

[Vladimír Cvajniga]

Is it possible to create an empty form (report) and use it somehow in MDE?
Ie. create controls, modufy class module code and run? IMHO, it would fix
some problems...

Vlado

 

[Vladimír Cvajniga]

IMHO, MS Acces limits are too low. 1000 objects and 2GB MDB file size is not
enough for large projects (nor programs, neither data storage!!!). Dynamic
objects (forms, reports, modules) or objects stored in a separate MDB could
solve this problem.

What I'm missing is a possibility to call a sub-project from the main
project. Main project should store common objects, functions & procedures,
sub-projects should store only its specific functions (procs, objects,
etc.).

Long time ago I was programming in Czech relation database system called PC
FAND. IMO, it was best DOS DB system ever. It's best feature was that it was
declaration-based. And it was possible to create REALLY HUGE structured
projects without any problem... well except RAM & HD limitations.

Vlado

 

[storrboy]

IMHO, MS Acces limits are too low. 1000 objects and 2GB MDB file size is not

enough for large projects (nor programs, neither data storage!!!).

Point me to a program (games don't count) that is over 2Gb in size
and
intended to be a desktop application. If you need more than 1000
objects
in one database file, you really shouldn't be designing it.

Dynamic
objects (forms, reports, modules) or objects stored in a separate MDB could
solve this problem.

You just disputed your first argument.

What I'm missing is a possibility to call a sub-project from the main
project. Main project should store common objects, functions & procedures,
sub-projects should store only its specific functions (procs, objects,
etc.).

Because as others have pointed out, you haven't spent much time
reading
or planning.

 

[Vladimír Cvajniga]

Have you heard about accountings? Earnings? Properties? Complete information
systems that include oll of those plus many many more? :O

Or do you play games only?

Vlado

 

[storrboy]

Have you heard about accountings? Earnings? Properties? Complete information
systems that include oll of those plus many many more? :O

Or do you play games only?

Vlado

Or perhaps the designers of those upsize to something other than a
desktop application. Ask Microsoft, EBay or Indigo if they run off of
Access. There are bigger hammers for bigger jobs. Don't complain when
your 5 oz ball-peen dosen't drive a 12" stake.

 

[Tony Toews [MVP]]

Is it possible to create an empty form (report) and use it somehow in MDE?
Ie. create controls, modufy class module code and run? IMHO, it would fix
some problems...

But you can't open an object in design view in an MDE.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Vladimír Cvajniga]

I'm affraid you don't know what you're talking about... Sry, I must quit
that discussion.
V.

"storrboy" <[email protected]> píse v diskusním príspevku

Have you heard about accountings? Earnings? Properties? Complete
information
systems that include oll of those plus many many more? :O

Or do you play games only?

Vlado

Or perhaps the designers of those upsize to something other than a
desktop application. Ask Microsoft, EBay or Indigo if they run off of
Access. There are bigger hammers for bigger jobs. Don't complain when
your 5 oz ball-peen dosen't drive a 12" stake.

 

[Vladimír Cvajniga]

Unfortunatelly, it's true. Can this be changed in future versions of Access?
What do you think?
Vlado

 

[Douglas J. Steele]

The most common solution is to create a form that has the maximum number of
textboxes that you'd need, and to toggle their visibility properties.

 

[David W. Fenton]

Is it possible to create an empty form (report) and use it somehow
in MDE? Ie. create controls, modufy class module code and run?
IMHO, it would fix some problems...

Create a generic form with controls and labels and at runtime, set
the recordsource, bind the controls to the appropriate fields,
change the labels and last position and resize the controls. That
will take care of your problem, though I can't for the life of me
figure out *why* you'd ever need to do such a thing.

 

[David W. Fenton]

IMHO, MS Acces limits are too low. 1000 objects and 2GB MDB file
size is not enough for large projects (nor programs, neither data
storage!!!). Dynamic objects (forms, reports, modules) or objects
stored in a separate MDB could solve this problem.

Or judicious use of forms and reports in a single Access project.

If you're really running into a problem like that, you can still use
library databases with your "extra" objects in those. It does cause
some issues for databound objects and can conceivable lead to
concurrency issues if you don't manage things correctly.

But I just don't see that the limits are problematic. I've never had
a front end over 50MBs (including embedded graphics!) nor one with
the number of objects that would come close to bumping up against
the limits.

Perhaps you're simply not re-using your forms and reports and
setting recordsources at runtime? If you do what lots of Access
novices do, and save a copy of a report for every single set of
criteria, you'll end up with way too many reports. I have plenty of
objects in my apps that dynamically change the recordsource at
runtime. Some even base themselves on different tables, depending on
the recordsource. And some hide/show/resize/move controls depending
on the context. I do this because I hate having two very similar
forms/reports that do slightly different things. I hate having to
maintain multiple versions of the same object, so instead, I make it
dynamic.

Perhaps that approach would relieve you of the need to have a
generic form.

 

[Vladimír Cvajniga]

As to me, I don't understand why MS has added those Create... functions to
Access. The only situation when I need to create a new form/report is when I
run out of resources (1000 objects). I NEVER use CreateForm/CreateReport.
When I'm in open MDB-project I often use design mode to create
reports/forms.

I have added "automatic reports" feature to my projects. They are based on
form's recordset. User has ability to select fields, sort, totals... plus
some more options (page breaks on group level, save/read automatic report
settings, etc.). To make it work I had to add a few template reports to each
of the project. Template reports contain "raw" controls and I "play games"
with this stuff.

The idea of automatic reports comes from Czech relational DB system PC FAND.
I just wonder why we don't have automatic reports in MS Access. :-/

BTW, I desperatly miss incremental search in MS Access, too. I had to create
one form plus some supporting code to have thic functionality in my
projects.

Vlado