how would you write this

[icemonster]

how would you write so that a function will not work if the record is new or when a button with the command

DoCmd.GoToRecord , , acNewRec

meanning that if me.newrecord then don't fire up function123 but if the record is not new, fire up function123.

 

[Galaxiom]

NewRecord is True if the current record is the New Record.

If Not Me.NewRecord Then
   function123
End If

I am sure you would know that. Maybe you need a break.

 

[icemonster]

ah. maybe i do need a break, but the function is still firing up.

i had the button open a new record here's the code i had embedded on the button

DoCmd.OpenForm "frm_LABREQUISITION_ADMIN_NEW", acNormal
DoCmd.GoToRecord , , acNewRec

then put the sub on the on load property of the form to be opened as

if not me.newrecord then
startTestList
end if

but it's still loading. lol.

 

[Galaxiom]

The Load event happens when you open the form which is before the command to go to the new record.

You could pass a flag as an OpenArgs argument with the open command and have the Form_Load Procedure test for it before running the function.

 

[icemonster]

can you elaborate?

 

[Galaxiom]

I would really need a better handle on what you are trying to achieve. The Form_Load test is never going to work because the form will always open on the first record not the new record. Tests like that are more usual in the On Current Event procedure.

OpenArgs is the last argument of the OpenForm command. It can be any interpretable expression or value and becomes the OpenArgs Property of the form while it remains open. So you can control the logic of what happens in the form's procedures by testing that property.

So if you want the form to open at the NewRecord then you could have an OnLoad test of the OpenArgs property. If it contains a particular character the procedure moves to the New Record and doesn't do function123. If it is opened without the OpenArg then the OnLoad does run function123.

That is just one way to use OpenArgs. Your imagination is the only limit to what it could be used for. It is often used to tell the form which record to move to by specifying the ID or to pass a filter string.

 

[icemonster]

i think i did what you have said, basically, i have this function taht starts an sql to a listbox's rowsource, but thing is, if it's a new record i don't want it to load, and i tried doing the WHERE clause in the sql and still not working. maybe i'm just tired and not seeing the code straight, (still a newbie after all) but if you have any way or something let me know, please and thank you sir

 

[r.harrison]

ah. maybe i do need a break, but the function is still firing up.

i had the button open a new record here's the code i had embedded on the button

DoCmd.OpenForm "frm_LABREQUISITION_ADMIN_NEW", acNormal
DoCmd.GoToRecord , , acNewRec

then put the sub on the on load property of the form to be opened as

if not me.newrecord then
startTestList
end if

but it's still loading. lol.[/
QUOTE]

Hi,

You could try passing a variable when you create a new record. Create a public Variable (PUBLIC NewRec as Boolean) and when you add a new record, set this to True. Then when you move from the new records, set it back to False.

 

[Galaxiom]

While the variable is also quite a serviceable way to do the same as the OpenArgs ,the use of this property is a very appealing alternative.

For one there is no need to maintain a variable to match the form. The value is a property of the Form Object itself. Each instance of the form carries its own OpenArgs Property. To do the same with variables would require a different variable to be used for each instance, breaking the notion of the object.

Object oriented thinking should always be encouraged. A good understanding of this principle saves vast amounts of work in writing a program and makes the code very efficient to run and maintain.

This is also often underappreciated in functions and subs where the principle should also apply. Sometimes we see functions reliant on the use of global variables internally. This is a bad practice and much better achieved by passing arguments to the function. This encapsulates the handover of information without having to look insde to see where other values are used.

A function should be treated as an object and the central focus of an object concept is the definition of the inputs and outputs. What actually goes on inside is of no real concern to the program using the function. The makes the function completely portable.

It makes sense with a function and we should try to think of objects like forms in this way too.

 

[r.harrison]

I appreciate the notion, however I have found in many situations that a simple global boolean can save hours of work arounds. Simple to Fire a true / false when needed then an exit function command if the value is False.

Sorry, I'm a completely self-taught programmer so I probably don't stick to conformity.

 

[Galaxiom]

Global boolean flags are a legitimate way to program, certainly are very useful and often entirely appropriate. In a way they can be considered as properties of the application.

For something that is progam wide makes sense. However in the case of controlling the behaviour of an instance of a form when it opens is more rightly thought of as a property of that instance of the form. That negotiation does not need to be advertised to the whole application, it is between the calling form and the called form.

The information is handed over in an encapsulated way by the calling form applying properties to its offspring. The situation will never arise where a global variable has an unexpected context. In good programming a variable should have only as much scope as it requires because it reduces the chance of such collisions.

Quite efficient code can be written without following these principles but the difference becomes apparent as the development of a program continues. Object orientied strategies with well defined, firmly attached handover of all information, it is far easier to maintain and reuse code in a modular structure.

Eventually skilled programers come to terms with creating their own portable custom objects where those who don't think in this way will still be custom coding every line in their new projects.

Many of us are self taught and so tend to go along with our experiences. It is unfortunate that some developers are not exposed to these concepts so I thought it worth a mention. That is why we come here to share our experience and knowledge.

 

[vbaInet]

While the variable is also quite a serviceable way to do the same as the OpenArgs ,the use of this property is a very appealing alternative.

Very appealing indeed. As GalaxiomAtHome mentioned, there's a lot you can do with OpenArgs. Also note that it's more persistent than a global variable (obviously within scope).

 

[r.harrison]

Thanks GalaxiomAtHome,

I have now re-written my Custom MsgBox to be totally self contained so I can use it anywhere. Will post some code in a relevant thread when I have tidied it up a little.

Thanks again GalaxiomAtHome.