I must first say I have had a ticket open on DevExpress support for several days now with no resolution. I thought maybe other developers here have the same problem, and maybe even a solution.
While using the 30 Day Trial, whenever a DevExpress component is create, or something, an immovable and large dialogue pops up on the screen, on the same thread (I think) that created the component. If there is an error or breakpoint in the code that triggered that dialogue, all is lost. The debugger is unresponsive, and the evaluation dialogue is unresponsive. To make matters worse, it always appears centre screen, obscuring the error message, as in the image attached. My only recourse is to restart VS, but what then? The same debugging sequence has the same effect again. At this rate I will need 300, not 30, days to evaluate the product.
EDIT: I have posted a ticket at http://www.devexpress.com/Support/Center/Question/Details/Q534381, and they are working on it.
According to my experience, a Trial Screen is expected when using a Trial Version.
However, the mentioned issue is not a proper behavior and should be changed.
In any case, I believe that only DevExpress support can assist you with this issue and put you on the right track in the most effective manner.
If you has already posted an inquiry to the support, share the corresponding link here.
Once you get a valuable response from the support team, post a new answer here and accept it to close the SO issue.
Related
I'm currently writing my master dissertation about version control in Ms Excel and would love to understand the problem more thoroughly. Does anyone face the problem and would be willing to discuss this in a 10min zoom call? Will hopefully be able to provide the solution in 2 months time.
t.muller#lse.ac.uk
Problem description:
If I'm working on a spreadsheet and need input from my co-workers on the same spreadsheet, I'd start to send the sheet around (probably via Email if we worked on excel offline). Unfortunately, we tend to quickly lose an overview of the different versions in the chain, and it sometimes even happens that some of us are mistakenly working on an old version. As soon as we managed to gather the input from everyone, we struggle to get to the root of newly introduced bugs and understand and approve all changes made.
I maintain a gtk3 (though a mixture of gtk2hs and gi-gtk) application that serves as a standalone status bar for tiling window managers called taffybar.
Taffybar has a long standing bug where something happens that causes one of its windows (it can have multiple windows e.g. when displaying on multiple monitors) to stop updating completely (issue here). I have verified through various logging mechanisms that the code that is supposed to be updating the window IS in fact continuing to run. Also, if taffybar is displaying on multiple windows, windows will become affected one at a time -- that is, the hang only seems to affect the window on which it occurs, which rules out anything strange happening on the UI thread or something like that.
Unfortunately, I do not have a consistent way to reproduce the issue. What's worse is that I haven't even been able to come up with a way to detect the issue programmatically. With that said, it is relatively easy to get the issue to occur as it has gotten much worse recently with the new icon loading mechanisms that have been added (it seems to happen about once every 5 minutes in the latest version). This reminds me that another thing I should mention is that I am relatively certain that the issue has something to do with pixbufs and image display because I have never seen the issue occur when the workspace images module is not active.
I hate to ask a question without even being able to provide a consistent way to reproduce the issue, but I'm simply at a loss as to how to go about tackling/debugging this issue. It's hard for me to imagine how the behavior that I have described is even possible, actually. I'm hoping that something about the idiosyncratic nature of the issue might be enough for someone more knowledgable about gtk than I to make some guesses as to what the issue might be.
To make my questions as explicit as possible I'll phrase it as follows:
What could cause a gtk application window to hang (stop updating) without crashing the application or the UI thread, or affecting any of the other windows created by the application?
EDIT: One more interesting quirk of this bug is that even though the window stops updating, it still responds to mouse input.
EDIT2: Another thing worth noting is that occasionally, I have gotten this message:
gtkicontheme.c:3956:proxy_pixbuf_destroy: assertion failed: (icon_info->proxy_pixbuf != NULL)
I have also gotten the following message when I attempt to destroy the hung window in code:
Source ID 363524 was not found when attempting to remove it
I am loading icons from the icon theme sometimes
I believe that the cause of this issue was simply that some UI updates were not being performed on the main UI thread. I can't be 100% certain of this because I was never able to reproduce. See this comment for more details:
https://github.com/taffybar/taffybar/issues/228#issuecomment-402591159
This is really unknown issue to many people. I would raise a question for it and make it easily accessible for other, and maybe someone of you know the solution for this problem.
All of us probably know that there is problem with alpha transparency in PNG24 in IE6 (still used by many people on web..). There are at least few known solutions how to solve that, but all of them got their problem that I would like to describe there:
1.Using progid:DXImageTransform.Microsoft.AlphaImageLoader:
This is most common trick to make images shown in IE6. Problem is that it uses DirectX to show it. So basically DX firstly need to download file from Net, then render it. This downloading block browser context for a while. But if you have alot of images - that means that you page can be freezed for even... few minutes (it happens to mine one project at least once).
http://blogs.cozi.com/tech/2008/03/transparent-pngs-can-deadlock-ie6.html
http://www.stum.de/2008/12/01/do-not-use-alphaimageloader-to-fix-transparent-pngs-in-ie6/
2.Using VML.
You can also use this workaround. However this has a nasty effect of rendering gray box in background, then a proper image, also causing to download image files twice - this however might be because of bad implementation so need to be checked.
3.Using PNG8.
Just forget about solutions and try use PNG8, if prepared correctly can still be looking good.
If anyone knows any other solution please give answer here!
You should definitely have a look at http://www.dillerdesign.com/experiment/DD_belatedPNG/
Introduction
I have been so annoyed by applications that have a startup dialog which is Always on Top configured.
By start dialog I mean the annoying box that tells you what program you just opened (and probably opened on purpose so useless information), who the program is registered to (most likely you, more uselessness), and some other random application specific information. Some have loading bars that indicate startup progress, but otherwise they seem basically useless except to show that your program is actually starting (to prevent the user from opening 5 instances during the loading process because they think it's not open yet).
The worst though is when this useless information is displayed over all the useful browsers and documents that I may be working on at the time, making me wait until the application is loaded before I can effectively work on something else again.
Most apps have the sense not to do this, but some still continue the practice.
Now that I'm done ranting...
My Question(s)
My question is..Why?
What is the point of all this?
Why does/did anyone ever do this?
What was the reasoning behind it?
Is anyone else annoyed by this?
Is there any benefit to the end user or developer to use this technique?
Should I ever use a startup dialog like this and when?
Anyone else have other comments/rants/suggestions to share with the community?
I believe you are talking about the 'splash screen.'
Some reasons for it:
It is often thought of as 'branding' in that it reinforces the company's logo.
It can contain some useful info such as version number.
Most importantly, it gives you the impression that the slow starting app is being just a bit more than unresponsive.
I share in your annoyance of Always-on-Top dialogs.
The use of the dialog is to let the user know that the application is actually doing something and hasn't hung. Back in the day, when IO wasn't as fast, it was reasonable to assume that the system is not very responsive while the application is doing its IO, so it was reasonable to bar the user from doing anything else while the application was loading.
Now that IO is faster and more concurrent, there isn't a need for hogging the user's focus and the start-up dialogs should simply be regular dialogs.
Since the main use of the dialog is to indicate application process, I like a visual indication, such as a progress bar. Eclipse does this well IMO.
It's good to have a startup screen so the user gets some feedback that they actually launched the app.
But putting that screen always on top of existing windows, so the user is sure to see it, is a definite no - you should not presume that your application is more important than the user's web browser, email, etc. Unfortunately many developers have a very self-centric view of the world, and think that their application is the most important thing the user is running.
Just gives visual indication that the app is initializing.
Startup dialogs or Splash screens are completely useless for the most part. The only time I think they are any use is if as you suggested a particular program takes a bit of time to load. Some kind of progress indication would be nice.
The only example I can think of is Photoshop. Not strictly necessary but it does take a moment to load.
I have an OLD server running DG/UX that will in the near future be unsupported. I have some character based oracle forms that need to be migrated off of this machine. Does anyone know what sort of migration strategy Oralce has for upgrading these Character Based reports. It doesnt have to be the newest version, it doesnt even have to be to a GUI version, but I do need to migrate to a supported OS such as linux.
The easy answer is to tell you to check out Migration from 6i to 10g.
Having done it before, what I think the much more useful answer is to tell you to rewrite those forms and reports from scratch. Probably in another tool - especially if you want to have a web interface, etc. rather than being hobbled by an ancient Java runtime.
There are products out there that will let you translate the old forms code into PL/SQL. Kumaran is an example of one, but I found it buggy and had to do a lot of hand editing of the code to get it work the same as the original.
As far as I'm concerned, the CUI is dead so you might as well go all the way to a GUI. The last time I was looking at it, there was almost no documentation for CUI forms and frequently things that worked in the GUI wouldn't work in the CUI at all.
There are some problems you may run into in converting CUI based forms applications to GUI.
Sometimes there is validation and special processing done when the user moves to the next or previous field/block/etc. When you switch over to a proper GUI, your user can skip those events by just clicking on another field. So you are left with two choices - #1 audit all of the forms or #2 disable navigation in the form with the mouse
Option #1 is less work than redeveloping but look at how much work we've already put into it.
Option #2 your users will HATE you and come after you with pitch forks and torches. They will perceive that they've got nothing of value for all the work you put into it. Then you will end up doing Option #1 anyway.
Sometimes a UI that works fine in (or is required by the limitations of) a CUI is just plain wrong and breaks the UI metaphor that users are used to working with in the rest of the GUI (e.g., a pop-up window with list that you have to select an entry in rather than pull down where you can just pick the right value directly)
When converted to a GUI the CUI may end up with different fonts, text sizes and other formatting defaults than a freshly written form (it did for me). So now either the whole set of forms has to be updated to follow Oracle's new default theme for forms/reports or every new form/report has to reverted back to the old clunky style you had before - or it will stick out like a sore thumb (and your users will want them all to be like the pretty one now).
Not the answer you wanted; huh. But you can use this as an excuse to get out of the Forms/Reports upgrade tread mill and maybe even clean up some of the hacks that have had to happen over the years.