FiveTech Software tech support forums

oGet:undo() -> works

Works only when oGet has focus. By any chance/mistake if oGet:undo() is called when oGet is out of focus, unexpected and undesirable results can happen.

oGet:cText := v:oGet:Original -> works

This works always.

Actually, I am testing and considering changing Undo() method ...

... you want to change the array at runtime (not before), set oBrw:aArrayData := <aNew>, but please do not use SetArray( aData ).

Calling SetArray() after the browse is prepared ( by Adjust() method) may have undesirable effects like this. This recommendation applies to other methods like SetRDD(), etc.

OT: AllTrim() for CHR(nKey) may not be necessary because CHR(nKey) is a single character and where nKey = 32, AllTrim() produces undesirable result of "" instead of the required " ".

Present behavior of RowSet Seek method:
Syntax:
oRs:Seek( uSeek, [lSoftSeek = .f.], [lWildSeek = .f.] ) --> lFound ...

... nDataType := 64

This is wrong.
Correct nDataType is DATATYPE_ODBF (16)

XBrowse automatically decides the correct datatype, when you create the browse based on the type of DATASOURCE.
Not only that you do not have to assign the value yourself, but it is also highly undesirable as in the above case.

... with dbfs, some arrays, some recordsets, some other kinds of datasources and thinking of one bInit for all is not good.

There will even be many undesirable or even dangerous side effects.

For the sake of dicussion, assume that we made bInit a class var and the programmer set it to :bInit ...

Enrico,

Yes, we are going to get all sort of undesirable effects, but this is the web and we have to live with it and try to solve what we can

... way of referring to column objects, from our experience with other browses. While we can access a column object like this, this is highly undesirable. With XBrowse the user can move the columns at the run time resulting in reordering of the columns. At runtime. oBrw:aCols[ 2 ] may not refer ...

... to the If ::bSetGet .... endif block.

This should give the desired behavior for you. Let us see if this solution works well and has no other undesirable side-effects.

Alternatively, keep the following line as the first line of your bLostFocus code block
&nbsp; &nbsp; Eval&#40; oGet:bSetGet ...

Thank you for the link. Looks good.

I'm not saying it is impossible to imitate mdi with sdi or even undesirable. I'm saying it is already working with mdi. I don't like to go back and change code that is working unless there is a bug to be fixed AND your changes will please the customers.

I call ...

... this is a static array in window.prg ) ..etc.
That means we are talking about disturbing the internal structure of the core fwh library with all undesirable consequences. Another fallout is that the object's destroy method is not called and the resources will not be released.
An object should be ...

... oApp&#58;aOpenForms&#41;

If I want to close a particular Window/Dialog, I can loop through the array and get the Window/Dialog Tile and then close.

But if I ever miss to Add or Delete information to this Array in the Application class, then I get undesirable results.



Regards

Anser

... character/word is out-dented to the preceding TAB stop and the new line is indented to the same point.

For reindenting of files it may be undesirable to indent certain lines that are commented out, or compiler directives. This can be avoided by specifying lines that should not be indented. To ...

... either currently, or in the future some or all of these codeblocks may have already been assigned by other methods of the TWBroiwse class. This could have undesirable effects.

I note also that neither TCBrowse nor TSBrowse are using DEFAULT.

My suggestion would be to not use DEFAULT.

Regards,
James

... Currently TButtonbar:blClicked is undefined when the bar is defined. When you left-click on the buttonbar it depresses like a button--rather undesirable. I find that if you do this:

oBar:blClicked:={|| .t. }

It doesn't depress anymore. It works the same if you return false. It would be nice if ...

... you wish to print to a different device, you need to rebuild the report. If you change the print device after the preview, this may have the undesirable side effect of the actual printed report not being exactly the same as the preview. The user will, of course, blame the program.

A better ...