|
|
>When you put a minor date that 19/09/1752, and you open the combobox this >shows your current date, and if you put a date between 20/09/1752 and >30/09/1752 gives an acces violation (I believe that it is for the limit of the >Gregorian calendar) You are quite right. Fixed in CVS >A separate suggestion is if the combobox of the TjvdbDatePickerEdit could be >the same that that of the TJvdbDateTimePicker AFAICS, they are the same? |
|
2004-02-21 11:42
|
image.jpg (21,168 bytes) |
|
|
I enclose an image to you so that you see what I want, is that the arrow of the combobox of the JvDBDatePickerEdit is the same one that the one of the JvDBDateTimePicker when xp is used the subjects of the Windows XP |
|
|
Oh, I see. XP theming...Not my area, I'm afraid. Maybe someone else can advice |
|
|
FYI: I'm currently reworking the validation fix as it broke basic functionality of the control again (esp. the raising of an exception for an empty date if AllowNoDate = False). Do you really think it should clear the control for such an out-of-bounds date? I will definitely have to add special handling of AllowNoDate = False ... might take some time to think this through... Also the other fix that was checked in at the same time (about the button being overwritten - I never saw this happen myself BTW - could someone maybe post some steps to reproduce?) does not look any good on my machine. I now have an extra 5 (or so) pixel right margin... :( |
|
|
Reminder sent to peter3 Peter, could you please comment on this? I've only got until tomorrow to work on this at best and your latest changes did only make matters slightly worse IMO. I'd like to discuss how to best address this, especially as I am not even able to entirely reproduce the supposed problems with the older version of the control (i.e. before your latest checkin). 1. AVs on "un-gregorian" date. Can reproduce this with neither the data-aware nor the normal control. I do agree however that some special handling has to take place in order to ensure consistent and predictable results. Note though that I couldn't really test the data-aware control as our db-server (or the BDE) is complaining about the invalid date even before the problematic code is reached. Apparently it couldn't handle dates before 1899 at all... Your fix as it is now is unacceptable for me as it no longer raises an exception when AllowNoDate = False. 2. Painting problems (you wrote "typing overpainted the button" in your commit comment). Cannot reproduce this with the older version of the control however hard I try. There's already the EM_SETMARGINS code (in the ancestor) to supposedly handle this and AFAICT it worked well. For me the only effect of the button holder control and the EM_SETRECTNP code that you added is that I get an extra right margin of about 5 pixels or more. This is annoying if the control is rather narrow to begin with. Under what circumstances were you seeing the overpainting? In any case, if any special should be needed for this I'd rather like to see it merged with the current margin handling code (UpdateControls/GetInternalMargin) instead. Cheers, Oliver |
|
|
OK, I have taken a look again. Here's a possible solution to satisfy us both: Change: function TJvCustomDatePickerEdit.ValidateDate(const ADate: TDateTime): Boolean; begin if (not AllowNoDate) and (ADate = 0) then RaiseNoDate; // 1752-09-14 - 1752-09-19 are the only valid days in october 1752. if (ADate < EncodeDate(1752, 09, 14)) or ((ADate > EncodeDate(1752, 09, 19)) and (ADate < EncodeDate(1752, 10, 1))) then Result := False else Result := True; end; Note that you can't include the gregorian check in the raise check/call, because you will end up in an endless raise loop. You can also remove TJvCustomDatePickerEdit.SetBounds and TJvCustomDatePickerEdit.CreateParams: they are not needed (this should also remove the 5 pixel margin although I can't see any additional margin here). The FButtonHolder must stay because without it, the button is overpainted every time the down arrow is clicked or when you type in the control (at least on w2k). |
|
|
Peter, thanks for your comments. > Note that you can't include the gregorian check in the raise check/call, > because you will end up in an endless raise loop. Yes, I figured that out as well. > You can also remove TJvCustomDatePickerEdit.SetBounds and > TJvCustomDatePickerEdit.CreateParams: they are not needed (this should also > remove the 5 pixel margin although I can't see any additional margin here). > The FButtonHolder must stay because without it, the button is overpainted > every time the down arrow is clicked or when you type in the control (at > least on w2k)." Just BTW: I'm on W2K as well (tested on two different machines with different locales) and I did see the extra margin and I did not see the "overpainting"... However, maybe I simply understood the meaning of that. What exactly did you mean by that term? I was thinking of the text (area) overlapping the button... Anyway, I'll commit my changes tomorrow morning. I had already prepared a little comment about the missing days in the Gregorian calendar and MS' faulty interpretation of it that should make it a little easier to figure out what the hell this bit of code is all about even in a few years' time... ;) |
|
|
> Just BTW: I'm on W2K as well (tested on two different machines with different > locales) and I did see the extra margin and I did not see the "overpainting"... I've attached an image that shows how it looks after typing in the edit control when there is no button holder |
|
2004-02-23 12:17
|
JvDBDatePickerEdit.gif (1,146 bytes) |
|
|
> I've attached an image that shows how it looks after typing in the edit > control when there is no button holder Strange. We've got dozens of instances of this control in all our apps which are in use for several years already at customers all around the world and nobody ever reported anything like this nor did I ever see this (except before I put the EM_SETMARGINS code in place but that was long before it ever shipped for the first time). Anyway, I'm not complaining. There's of course no harm in the holder control. I just didn't see the point of it as to me it always seemed to be working without it... has this always been this way for you or did it break only recently? |
|
|
Peter, I've checked your code and the extra margin is still there for me even with the EM_SETRECTNP call removed. Only by removing the button holder do I get desirable results... this is appears to be a deadlock situation as it is just the reverse for you obviously... :( |
|
|
BTW: I'll open a new item for the paint bug as the original issue of this item (the Gregorian adjustment) has been fixed AFAICT. As for the theming issue I also suggest opening a new bug for it. I am however as much at a loss with this as Peter. I don't use XP myself and do not even have access to a testing machine. The control just loads a standard named resource (OBM_COMBO) for the button image. Obviously it is not the one used by the native Microsoft control... |
|
|
I have now created two new items for the two remaining issues discussed here (0001361 and 0001362). I could not completely verify the effectiveness of the Gregorian adjustment fix myself as I never got any AVs before either so I'm not closing this one myself yet... |
|
|
> has this always been this way for you or did it break only recently? I can't say because I don't regularly use it and just discovered it while trying to find a fix for the original date problem. BTW, Ive tried the control with and without the button holder on three different machines (all running w2k, though) and they all exhibit the same behavior as in my original test |
|
|
Since two posts new are closed I it will put here the bugs: - The new control me works already correctly with the theme of the windows xp, the only snag that I have found him is that it works in a way different from the rest of combo since when you pulsate to the button of the combo and this one it was already showing the calendar , this does not hide the calendar, it but it re-draws it again - When he pressed the intro or attempt to change the property DateFormat an error of the type "Invalid input value", nevertheless if I change his property and it was too tight with the mouse to another property to the second attempt it changes it to me, but not there way of which it changes it again |
|
|
Xerkan, "Since two posts new are closed I it will put here the bugs:" please don't. It's much easier for us to track what's going on if every single issue is represented by a unique tracker item. That said, I'll try to take a look at your first issue (about the dropdown button) tomorrow. I can't guarantee anything this week in case it turns out to be non-trivial though... Concerning the second issue I'm sorry to say that I again do not understand what you're trying to say. From our last encounter I discovered that two of my acquaintances are actually fluent in Spanish (although you appear to be writing Portuguese?). Maybe rewriting that report in your native language might get me somewhere by asking those people to translate it for me... |
|
|
Bueno pues lo esplicare en mi idioma :) La primera cuestion es que cuando depliegas el jvdbDatePickerEdit y le das de nuevo a la flecha para que se cierre este se redibuja en vez de cerrarse (q es lo que hacen todos los combobox) La segunda cuestion es que al modificar la propiedad DateFormat y pasar a modificar otra propiedad salta un error de "Invalid input value" aunque al final si que cambia el metodo de introduccion de datos en el jvdbDatePickerEdit (prove a cambiarlo a yyyy/mm/dd) pero luego cuando intento dejarlo como estaba no me hace caso. PD: Por si sirve de algo las pruebas las hago en un delphi 7 bajo winxp español (no portuges) |
|
|
OK, I've been able to fix the "Invalid Input" issue rather easily. However the dropdown button thing turned out to be trickier than I expected - or maybe I'm simply blocked at the moment... :( Anyway, I'll try thinking of something for another half an hour and if I couldn't come up with something satisfactorily, I'll just commit the SetDateFormat fix and create a new tracker item for the DropDown button issue as I probably won't have any more time for this today... |
|
|
OK, fixed and committed both issues now (<phew>). In the process I even discovered and fixed yet another recently introduced AV bug... :) Please verify your two issues have really been fixed, so I could finally close this bug. Please do not report any more unrelated issues within this bug. |
|
|
Pues parece ser que el error del DateFormat funciona, pero la otra va peor que antes ahora el calendario se muestra en la mitad del escritorio y sigue sin cerrarse al apretar el boton del combo cuando esta el calendario desplegado, es mas e visto que cuando el calendario esta desplegado y se pincha en cualquier sitio del escritorio me sale un mensaje de access violation. Para que veas lo que me pasa te adjunto la url de un video con el control, el campo desde incluye un componente del tipo TjvdbDatePickerEdit, y el campo hasta uno del tipo TjvdbDateTimePicker. http://www.terra.es/personal3/dcanyas/video.zip |
|
|
I get a "Not found" error on the URL you gave... although the message is indicating that this is maybe because I am not allowed to access that page. If the file is below 1MB you could send it to ogware AT gmx DOT net, otherwise please send it to giesen AT lucatec DOT de and I'll have a look at it tomorrow. If you could resolve the issue with the download URL I'd still prefer that though. |
|
|
Lo siento, pero borraron del servidor que habia puesto el archivo, bueno lo e subido a otro servidor q imagino aguantara mas, de todas maneras si lo borran de este mañana me pongo un servidor ftp en mi equipo para que se baje de este. http://webs.ono.com/dcanyas/video.zip |
|
|
Hmm, what codec did you use to produce that video and where can I get it? My media player won't play it. |
|
|
Neither will mine... |
|
|
Xerkan, are you sure you were using the latest version of JvDatePickerEdit.pas (CVS rev. 1.27)? Two of the bugs shown in the video (the reopening dropdown button issue and the AV when clicking outside the app) are exactly what I fixed between 1.26 and 1.27. Where are you getting the sources from? If you are not accessing the CVS repository via SSH, you should be aware that there could be a lag of up to 24 hours in the worst case until the read-only CVS repository (accessed anonymously via :pserver:) or the ViewCvs pages are back in sync. However, your video showed two new bugs that should be handled indeed. I'll open new tracker items for them as soon as I could sufficiently reproduce them myself. |
|
|
BTW: To anyone listening in: The video requires the DivX codec. |
|
|
Si acabo de volver a bajar el repositorio del cvs y el error del boton del combo y el del access violation ya no me salen ;-) Uno de los bugs que dices imagino que sera cuando le metes directamente una fecha con un año inferior a 1752 (para hacerlo la base de datos q estoy usando es la firebird) al introducirlo se cambia visualmente a 0??? siendo las interogantes las 3 primeras cifras del año, pero se ve q no se guarda sino q deja el valor anterior. El otro bug que dices no se cual es... |
|
|
Vale el otro bug es el de la posicion del calendario al desplegar el combo, lo que pasa es que no ocurre siempre, ocurre si pones la fecha cerca de la parte inferior del formulario, pero si lo pones en la parte superior no ocurre. Abrire dos hilos nuevos exponiendolos segun lo dicho anteriormente editada el: 02-26-04 12:31 |
|
|
OK, now that the remaining issues have been split into new items 0001379 and 0001380 I'm closing this one now. Unfortunately I don't have much time to work on this at the moment, so if anyone feels like jumping in just go ahead. |
- Anonymous
