View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001450JEDI VCL04 Feature Requestpublic2004-03-08 07:082004-04-30 04:28
ReporterIgnacio VazquezAssigned Touser72 
PrioritynormalSeveritytweakReproducibilityN/A
Status resolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0001450: Be able to store form position independent of size in TJvFormStorage
DescriptionCurrently the TJvFormStorage component stores both position and size when fpPosition is included in the Options property. I propose that another option be added, fpSize, which would indicate that the forms size should be stored but not its position.
TagsNo tags attached.

Activities

user72

2004-03-08 14:49

  ~0003265

I'd suggest to add a fpNoSize property instead. That way the current behavior of fpPosition will continue to work as before but if fpNoSize is defined, only top/left is (re)stored. This would be the most backward compatible implementation, IMO.

Ignacio Vazquez

2004-03-09 07:23

reporter   ~0003284

While that certainly works to separate position and size, how does that indicate that only size will be saved, as was given in the original proposal?

marcelb

2004-03-09 07:54

manager   ~0003288

I agree with Ignacio. I know this will break backward compatability (again) but the converter could change any reference to fpPosition to fpPosition, fpSize in the DFMs and it's fixed again (of course we should make sure that if fpPosition is the default for the property we make that fpPosition, fpSize as well; I don't think many users will set that property from code).

user72

2004-03-10 01:05

  ~0003294

I really don't like it when properties change meaning, especially when they loose functionality. Removing them I can accept (with good reasons) since then people with get an error when they use it.

How about:
fpPosition: stores everything (as now)
fpSize: stores width/height only, regardless of fpPosition
fpLocation: stores top/left only, regardless of fpPosition

A bit kludgy, but I really would like to avoid changing the meaning of fpPosition. Imagine the problems it could cause (shudder)...

jfudickar

2004-03-10 02:27

developer   ~0003296

Then it will be better to remove fpPosition.

user72

2004-03-11 01:57

  ~0003315

> Then it will be better to remove fpPosition.
Don't like that one either...

craigism

2004-03-12 13:15

reporter   ~0003324

Last edited: 2004-03-12 13:16

 Common Jv units from my uses clause:
...
JvToolEdit, JvComponent, JvAppEvent, JvExControls, JvDBLookup,
JvFormPlacement, JvAppStorage, JvAppIniStorage; <<<<

Not that I really mind, but are any of these (<<<<) three small enough to be combined into one unit? For me, they always seem to be used together. Just a thought.

-Craig

edited on: 03-12-04 13:16

user72

2004-03-13 00:26

  ~0003327

Not really: JvFormPlacement holds the TJvFormStorage component that can (but don't have to) use a TJvAppStorage descendant component. JvAppStorage defines the base classes for components that are app storages, JvAppIniStorage is one of several such implementations.

user72

2004-03-13 15:48

  ~0003334

So, what is the general consensus? Should we do it or not and, if yes, how?

user72

2004-03-14 04:12

  ~0003341

Since no one seems up to it, I'll try to modify it to use fpSize and fpLocation and remove fpPosition. I thought about keeping fpPosition but I think it will be too much trouble. I'll post any updates to this issue and we can update the CVS when ready.

Does anyone know a way to read a removed enum (fpPosition in this case) from a dfm?

2004-03-14 14:06

 

JvFormPlacement.zip (54,776 bytes)

user72

2004-03-14 14:07

  ~0003344

I've attached a zip with the modified files. Still don't know how to detect a fpPosition in the dfm and convert it to [fpSize,fpLocation]. Apart from that, this version seems to work fine.

user72

2004-04-02 11:10

  ~0003607

Did the interest in this issue vanish? Has anyone tested it?

marcelb

2004-04-02 11:24

manager   ~0003611

I have no issues with the change to fpLocation + fpSize. I have not tested it (too be honest, if I hadn't received a notification mail just now, I would even have remembered this issue at all and I was completely unaware of the final decision)

user72

2004-04-26 10:07

  ~0004086

Since there doesn't seem to be a solution imminent to reading the previous fpPosition property, shoud I go ahead committing the proposed changes this or should we forget about it?

marcelb

2004-04-30 02:26

manager   ~0004137

Peter, as far as I'm concerned you can go ahead and commit your fix.

user72

2004-04-30 04:28

  ~0004141

Will update ASAP

Issue History

Date Modified Username Field Change
2004-03-08 07:08 Ignacio Vazquez New Issue
2004-03-08 14:49 user72 Note Added: 0003265
2004-03-09 07:23 Ignacio Vazquez Note Added: 0003284
2004-03-09 07:54 marcelb Note Added: 0003288
2004-03-10 01:05 user72 Note Added: 0003294
2004-03-10 02:27 jfudickar Note Added: 0003296
2004-03-11 01:57 user72 Note Added: 0003315
2004-03-12 13:15 craigism Note Added: 0003324
2004-03-12 13:15 craigism Note Edited: 0003324
2004-03-12 13:16 craigism Note Edited: 0003324
2004-03-13 00:26 user72 Note Added: 0003327
2004-03-13 15:48 user72 Note Added: 0003334
2004-03-14 04:12 user72 Note Added: 0003341
2004-03-14 04:12 user72 Assigned To => user72
2004-03-14 04:12 user72 Status new => assigned
2004-03-14 14:06 user72 File Added: JvFormPlacement.zip
2004-03-14 14:07 user72 Note Added: 0003344
2004-03-16 03:59 user72 Status assigned => feedback
2004-04-02 11:10 user72 Note Added: 0003607
2004-04-02 11:24 marcelb Note Added: 0003611
2004-04-26 10:07 user72 Note Added: 0004086
2004-04-30 02:26 marcelb Note Added: 0004137
2004-04-30 04:26 user72 Status feedback => resolved
2004-04-30 04:26 user72 Resolution open => fixed
2004-04-30 04:28 user72 Status resolved => feedback
2004-04-30 04:28 user72 Resolution fixed => reopened
2004-04-30 04:28 user72 Status feedback => resolved
2004-04-30 04:28 user72 Resolution reopened => fixed
2004-04-30 04:28 user72 Note Added: 0004141